Re: RFC: Additions to dpkg's Pre-Depends

[Guillem Jover <guillem@debian.org>]

On Wed, 2022-07-06 at 16:45:18 +0200, Andreas Henriksson wrote:
> On Wed, Jul 06, 2022 at 05:13:05AM +0200, Guillem Jover wrote:
> [...]
> > * libaudit-dev
> >   - Rationale:
> >     This could allow to add Linux audit support to dpkg on package action
> >     events. I've got a branch that might need minor polishing, but could
> >     otherwise be merged.
> > 
> >   - Essential/Build-Essential:
> >     On Linux it is already part of the pseudo-essential set.
> [...]
> > * libcap-dev
> >   - Rationale:
> >     This could allow to add support to start-stop-daemon (already code
> >     available) to drop POSIX capabilities. And also in the future (either
> >     later in 1.21.x or 1.22.x) to support fsys POSIX capabilities as part
> >     of the fyss metadata tracking support that is upcoming.
> > 
> >   - Essential/Build-Essential:
> >     On Linux it is already part of the pseudo-essential set.
> [...]

> IIRC there are several competing capability libraries already part of
> pseudo essential. I think it would be good if we could identify one and
> work towards having only that in pseudo essential (and in theory maybe
> the entire archive use it). Maybe it's out of scope for this discussion
> though...

Ah, sorry, should have included that as part of the rationale too.

When I looked into this, I checked both libraries, their size, the
amount of users and their APIs. And my conclusion was that libcap-dev
looked like a better choice, even if it might be supposedly harder to
use (which I found it to be the reverse, given it has an explicit API,
instead of one based on hidden global state), but then libcap-dev API
could always be improved or a new higher-level layer added on top.

  * libcap-ng-dev
    - Installed size 66 KiB.
    - 27 source packages Build-Depend* on it.
    - Uses (thread-local) hidden global state, when dealing with files
      f.ex, which makes this unintuitive and rather unattractive when
      being used from a library (eventually this would end up in
      libdpkg.so), after that I didn't look further into this library.
      I think ideally this this library could have been either built on
      top of libcap-dev, or any more higher-level interfaces added there.

  * libcap-dev
    - Installed size 65 KiB.
    - 121 source packages Build-Depend* on it.
    - The API looks less constrained and better to use from another
      library.

(FWIW, I also think unifying on a single library distro-wide would be a
nice goal, though.)

> Unless I'm mistaken if dpkg dep on libcap(2) and libaudit, then dpkg
> would transitively dep on both libcap(2) and libcap-ng which seems
> suboptimal.

Yes, but its an internal implementation detail, so libaudit could be
switched, and for now, at least they will not end up in the same address
space. Of course pulling both is not ideal, but on Linux they are both
already part of the pseudo-essential set anyway, and they are tiny
compared to say the libzstd one, so…

Thanks,
Guillem