Hi, Quoting Ansgar (2024-01-07 20:39:57) > I would like to extend Debian Policy on libraries depending on services > (daemons) that they can speak to. > > Let me bring to examples, one made up,, one for which I filed a bug > recently. But as far as I can tell this question comes up from time to > time: > > 1. libpulse0 & friends > ---------------------- > > libpulse0 is a client library for the Pulseaudio server. It doesn't do > much without pulseaudio. > > Q: Should libpulse0 have Depends: pulseaudio? > > There a similar libraries like libjack0 to talk to Jackd. > > Q: Should libjack0 have Depends: jackd1? > > The answer should probably be the same for both questions. another entry to the "it depends" that wasn't mentioned yet (I think) is build dependencies. Shared libraries are pulled in by *-dev packages (libpulse-dev and libjack-dev for above examples) but I guess there are only rare cases where a service or daemon is required for building something and if it is, it is probably not pulled in via any *-dev build dependencies but by an explicit build dependency on the service. So I think something to keep in mind during this discussion is, that any changes to shared library dependencies will also change what build dependencies ultimately get installed into the build chroot. Just today I had a case where I was building something innocent and suddenly I had an init system installed because: libgtk-3-dev -> libgtk-3-common -> dconf-gsettings-backend -> dconf-service \ -> dbus-session-bus -> dbus-user-session -> libpam-systemd -> systemd-sysv I'm sure all of these packages have a very good reason to depend on the next one in the chain but my source package just wants libgtk-3-dev and not a full blown init system in its build chroot. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature