On 22/11/2024 19:02, Andrey Rakhmatullin wrote:

On Fri, Nov 22, 2024 at 11:09:04AM +0000, Ahmad Khalifa wrote:

I don't see a rule prohibiting that

Public shared libraries must be installed in a package with the name based
on the library SONAME (see Policy 8.1; you must read the whole of Policy 8 when packaging a public shared library). Even if it's fine for your
package (so the tool is less important than the library), packages with different SONAMEs of the same library should be co-installable.

I was thinking the tool is more important than the library and chapter 8
starts off by saying "Shared libraries that are internal to a particular package [...] are not subject to its requirements."

But it seems safer to split them regardless of how unlikely it is to be
used since there aren't lots of examples.


--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 23, 2024 at 02:35:30PM +0000, Ahmad Khalifa wrote:

I don't see a rule prohibiting that

Public shared libraries must be installed in a package with the name based on the library SONAME (see Policy 8.1; you must read the whole of Policy 8 when packaging a public shared library). Even if it's fine for your
package (so the tool is less important than the library), packages with different SONAMEs of the same library should be co-installable.

I was thinking the tool is more important than the library and chapter 8 starts off by saying "Shared libraries that are internal to a particular package [...] are not subject to its requirements."

Sure. Those don't have -dev so I assumed this is not your case.


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdCHSktFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh AXMP/2/pvoNa2h6KYzGcv0f5TsN9N0flcxPbSyzFKFtssDwbFL+WGv/VbX8RmV9J yVqyh9LGnCT7OY6w/3vYn14iS08bFGpcSnfQrkIcnyktFjrAB8LPiTnQqFxdIP/w hdTITIyy0uE6ok0CMq6H0xmRTXL8Ybc+ZKnFU9gmzZoBZvJ3BW+pRmt8KSmQQSs9 OO5aw0BiJ1res55BAEt3LlqaIvJRKZXk+GqvaywXO88TsrXXyYysrzCvm1HZguP7 y7E4jxo7bWDZIMJzLuAIJsdNhEcVOZxI2tnvAtIm6Xwe1431AIFNmw/kPh68ngoi vJycniHEECJlJy2PSaYb95pT9F2XzMtMO68DYQL20g6QaZT4SIgGTMjCX0sVA5XH 45py4M7GEemcE1bKl/ATCi2QS1BG1+tUFMI+Mn+C/bI5j1jyyTzdL9YFQJam6d7F LGrMMKQ4DpDuTIGALkYzqrnPg5awP5Mu3j6newo4nM3Zta2ENFimcz63VJruPmIf JNLaH7QBiyKxG0QduEc2B1EpTwb3P4MDgR+3JHcvCw9ZWRZ3ijPHeoULffQWZbxM R6yrnIjqXgtTRHsPzmStiXrUFAQ9lrIE3mmrrAyyLbICgkxHJVnWAmSHOl4VjHg0 YMKcyWGNRZ5notUU/O9qroeJmUkCh3y5C+hY6hGX7nDNVk1s
=05mF
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

I'm trying to see if I can handle packaging a utility but I'm looking
for some example packages to help me figure a few things out:

1. Package installs bin+lib+headers, typically this would be 3 packages
(tool, libtool, libtool-dev), but could it be packaged as 1 with all
three parts?
I don't see a rule prohibiting that, but I can't find any clean examples either. Does this happen or is it allowed?

2. Upstream has a .service file (outside d/) that is installed through a
make target. How can I get dpkg-buildpackage to spot that and enable the service? It seems to ignore .service files outside debian/ and trying a
rule "override_dh_installsystemd" doesn't generate any triggers.
Does this mean I need a postinst file? Any example packages would be appreciated

3. Upstream tests have kernel-level tests with bpf objects that need to
be run as root. I'm not sure running those tests in a chroot isolates
the host kernel from them.
Should those be switched off? If not, any examples of
"Rules-requires-root: binary-targets" and how to elevate privileges for
tests only would really help.


For reference, it's about this RFP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087756


--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Nov 22, 2024 at 11:09:04AM +0000, Ahmad Khalifa wrote:

I'm trying to see if I can handle packaging a utility but I'm looking for some example packages to help me figure a few things out:

1. Package installs bin+lib+headers, typically this would be 3 packages (tool, libtool, libtool-dev), but could it be packaged as 1 with all three parts?

No.

I don't see a rule prohibiting that

Public shared libraries must be installed in a package with the name based
on the library SONAME (see Policy 8.1; you must read the whole of Policy 8
when packaging a public shared library). Even if it's fine for your
package (so the tool is less important than the library), packages with different SONAMEs of the same library should be co-installable.

Does this happen or is it allowed?

I'm sure it happens from time time. It's not allowed.


--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmdA1UMtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh ZJ4P/Rh5++4Gyxnuf2PkXz7r5yKZ1Lr4ZBxgkZ4eAEJfOU3/HAklq9mJAFdlLxxo XVj9QmTmyA/Y82aEFGalKdNPCvQZ+QlYBjCyE3uAGuftpjNrHj8Cx3x3X2Lalt2o 4skNOUWXXUMjpmu9P8EmTINBXHxmP5rdl18m9l5pj2sQh//lkpXdFyYfSh1ZqQQo FKJUj7T9MQxxuIbNWKFAB20/1Sxu1By34WomQNQllyRkPtpX+CPba/JjncVbVcr6 g6smPWtSDljuWRQlGBKxJIiFuflfl1GByhqKIcZwGURSRnm5LqW90Xovv3+IUy7n RSr+L4EijByzuSJhndJUXgIWD6dWSGtG9lqssfWR6wdICIds1BxHyavQqw71+pOZ V8dDeAVGj1/Yu6t4hS+y1KvClidJmFJED33u10JoDcxMIgv5d86c/4ubO+thJSNT 07ZQRegg1xRy+iA8ehhtvT7AuuEip4Wwt5mdlBFU7gWgCx+GBwv5rH6C5fPsdDZe WRk9+LyQAFTxoB71thYPsGf/1ZToSseOd9mHSRer39WZSF6dtHFNGJEQsIcz7Gr5 hXi+wbM3fsqoWLx4scwnnAIc3ouw5Jz00csyMxbb7Jqe9nBSUuwPU5tNGhx3iKtI ZmmOFk4ulB9RpQLsQK0MJ6o7bN7ynGjIUapmn/sL4vwsmCuy
=2Kkz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)