[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy: should libraries depend on services (daemons) that they can speak to?




On January 7, 2024 7:39:57 PM UTC, Ansgar <ansgar@43-1.org> wrote:
>Hi,
>
>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.
>
>If the answer is "yes", this would result in an application that can
>output audio via Pulseaudio or Jackd and linking the respective
>liubraries pulling in *both* Pulseaudio and Jackd (and possibly other
>sound servers as well).
>
>2. python3-secretstorage
>------------------------
>
>python3-secretstorage is a library to talk to a Dbus Secret Store API
>implemented by several programs (gnome-keyring, libkf5wallet-bin,
>keepassxc).
>
>Q: Should python3-secretstorage Depends: default-dbus-session-bus |
>dbus-session-bus?
>
>Q: Should python3-secretstorage Depends: gnome-keyring | ...?
>
>If the answer is "yes", this would result in an application that can
>manage credentials via Secret Store to pull in DBus, systemd-sysv,
>gnome-keyring, and lots of other stuff, even when one just wants to,
>for example, install (public) packages from PyPI (#1058945).
>
>(There is a practical different between Python and C in that Python
>makes it easier to handle optional linkage: just try `import foobar`
>and handle the import error; proper plugin handling in C is
>significantly more work.)
>
>3. The general case
>-------------------
>
>Many Debian packages build with a large set of optional features
>enabled, thus linking many libraries. I believe that if all libraries
>implementing support to talk to some service would mandate installing
>said service, then this would result in many installations getting many
>more packages, especially when also considering use of software in
>containers.  Some service might even conflict with each other, e.g.,
>one would probably only want to use a single sound server.
>
>I therefore think that libraries (be it classic C shared object
>libraries or Python modules or others) should in general *not* have
>Depends: or Recommends: relations on services (DBus services, DBus
>itself, daemons, ...).
>
>A quick poll on IRC in #-devel seemed to show a majority of people who
>responded agreeing with this.
>
>(This does not have to apply to libnss-* or libpam-* which are not
>actually libraries, but plugins.)
>
>Ansgar

I think this is correct.  I believe the appropriate relationship is Suggests.

Scott K


Reply to: