1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL.MENTOR

  • Examples for single bin+lib and service triggers

    From Ahmad Khalifa@21:1/5 to All on Fri Nov 22 12:10:01 2024
    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)
  • From Andrey Rakhmatullin@21:1/5 to Ahmad Khalifa on Fri Nov 22 20:10:02 2024
    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)
  • From Ahmad Khalifa@21:1/5 to Andrey Rakhmatullin on Sat Nov 23 15:40:01 2024
    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)
  • From Andrey Rakhmatullin@21:1/5 to Ahmad Khalifa on Sat Nov 23 19:30:01 2024
    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)