Examples for single bin+lib and service triggers

[Ahmad Khalifa]

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

[Andrey Rakhmatullin]

I'm trying to see if I can handle packaging a utility but I'm looking for
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.

[Ahmad Khalifa]

Post by Andrey Rakhmatullin

Post by Ahmad Khalifa
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.

[Andrey Rakhmatullin]

Post by Ahmad Khalifa

Post by Andrey Rakhmatullin

Post by Ahmad Khalifa
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.