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

[Jonas Smedegaard]

Quoting Vincent Lefevre (2024-03-06 12:17:55)
> On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote:
> > Quoting Arnaud Rebillout (2024-03-06 02:26:00)
> > > However it's true that some packages are installed before that, at the 
> > > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?
> > 
> > Correct.  This is tracked as bug#742977
> 
> Bug#742977 is about whether to mark installed packages as
> auto-installed or not. It is not about Recommends.

Sorry. You are right, of course.

It is another related issue.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

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

[Vincent Lefevre]

On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote:
> Quoting Arnaud Rebillout (2024-03-06 02:26:00)
> > However it's true that some packages are installed before that, at the 
> > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?
> 
> Correct.  This is tracked as bug#742977

Bug#742977 is about whether to mark installed packages as
auto-installed or not. It is not about Recommends.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Jonas Smedegaard]

Quoting Arnaud Rebillout (2024-03-06 02:26:00)
> On 05/03/2024 9:22 pm, Vincent Lefevre wrote:
> > On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:
> >> For example, when I implemented libuuid, if you want to create a huge
> >> number of UUID's very quickly, because you're a large enterprise
> >> resource planning application, the the uuidd daemon will allow
> >> multiple processes to request "chunks" of UUID space, and create
> >> unique UUID's without having to having to go through some kind of
> >> locking protocol using a single shared state file.
> >>
> >> So libuuid works just fine without uuidd, but if you are populating a
> >> large ERP system, then you very much will want uuidd to be installed.
> >> So in that case, you can make the dependency relationship be either
> >> suggests or recommends, instead of a hard dependency.
> > Except that in Debian, this is a "Recommends:", and "Recommends:"
> > are normally installed by default... except by the Debian installer!
> > This is inconsistent.
> 
> This is not correct. The majority of the packages installed by the 
> installer are in fact installed via tasksel, and it does install 
> "Recommends:". The command is there: 
> https://salsa.debian.org/installer-team/tasksel/-/blob/546b5b99e81bfb69b88de105b6fc78fceacb5ee1/tasksel.pl#L930.
> 
> However it's true that some packages are installed before that, at the 
> debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?

Correct.  This is tracked as bug#742977


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

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

[Arnaud Rebillout]

On 05/03/2024 9:22 pm, Vincent Lefevre wrote:

On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:

For example, when I implemented libuuid, if you want to create a huge
number of UUID's very quickly, because you're a large enterprise
resource planning application, the the uuidd daemon will allow
multiple processes to request "chunks" of UUID space, and create
unique UUID's without having to having to go through some kind of
locking protocol using a single shared state file.

So libuuid works just fine without uuidd, but if you are populating a
large ERP system, then you very much will want uuidd to be installed.
So in that case, you can make the dependency relationship be either
suggests or recommends, instead of a hard dependency.

Except that in Debian, this is a "Recommends:", and "Recommends:"
are normally installed by default... except by the Debian installer!
This is inconsistent.


This is not correct. The majority of the packages installed by the 
installer are in fact installed via tasksel, and it does install 
"Recommends:". The command is there: 
https://salsa.debian.org/installer-team/tasksel/-/blob/546b5b99e81bfb69b88de105b6fc78fceacb5ee1/tasksel.pl#L930.


However it's true that some packages are installed before that, at the 
debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?




So, in the present case, uuid-runtime wasn't installed by default,
though libuuid1 was installed and had a "Recommends: uuid-runtime".

But with the 64-bit time_t transition, libuuid1 got replaced by
libuuid1t64 a few days ago, which pulled uuid-runtime.


Looking at some install logs, I can confirm that libuuid1 is installed 
by debootstrap (as a dependency of e2fsporogs), and that explains why 
uuid-runtime is not installed.

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

[Vincent Lefevre]

On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:
> For example, when I implemented libuuid, if you want to create a huge
> number of UUID's very quickly, because you're a large enterprise
> resource planning application, the the uuidd daemon will allow
> multiple processes to request "chunks" of UUID space, and create
> unique UUID's without having to having to go through some kind of
> locking protocol using a single shared state file.
> 
> So libuuid works just fine without uuidd, but if you are populating a
> large ERP system, then you very much will want uuidd to be installed.
> So in that case, you can make the dependency relationship be either
> suggests or recommends, instead of a hard dependency.

Except that in Debian, this is a "Recommends:", and "Recommends:"
are normally installed by default... except by the Debian installer!
This is inconsistent.

So, in the present case, uuid-runtime wasn't installed by default,
though libuuid1 was installed and had a "Recommends: uuid-runtime".

But with the 64-bit time_t transition, libuuid1 got replaced by
libuuid1t64 a few days ago, which pulled uuid-runtime.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Simon Richter]

Hi,

On 1/16/24 03:55, Simon McVittie wrote:


I would personally like to see *more* privilege separation across IPC
boundaries rather than less, if that can reduce the total attack surface
of the setuid/setcap executables in the trusted computing base.


Yes, however there is a downside to building IPC microservices this way: 
we are now dynamically building trust chains, and the entire chain is 
not visible as the orchestrator can only witness individual connections 
between black boxes (same as socket activation hides dependencies 
between services).


So we might have a component that has no special capabilities, but it is 
privileged by the trust relationship from other components, which may in 
turn have capabilities. Such components with incoming trust 
relationships would _also_ have to be written with minimal dependencies, 
and lots of mitigation code -- so while we're reducing the impact of a 
breach, I fear we're increasing attack surface by adding more privilege 
domains, and declaring some of them as "less critical".


   Simon

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

[Russ Allbery]

Roger Lynn  writes:
> On 15/01/2024 18:00, Russ Allbery wrote:

>> When you have the case of an application that optionally wants to do foo,
>> a shared library that acts as a client, and a daemon that does foo, there
>> are three options:
>>
>> 1. Always install the shared library and daemon even though it's an
>>optional feature, because the shared library is a link dependency for
>>the application and the shared library viewed in isolation does require
>>the daemon be running to do anything useful.
>> 
>> 2. Weaken the dependency between the shared library and the daemon so that
>>the shared library can be installed without the daemon even though it's
>>objectively useless in that situation because it's the easiest and
>>least annoying way to let the application be installed without the
>>daemon, and that's the goal.  The shared library is usually tiny and
>>causes no problems by being installed; it just doesn't work.
>> 
>> 3. Weaken the dependency between the application and the shared library,
>>which means the application has to dynamically load the shared library
>>rather than just link with it.  This is in some ways the most "correct"
>>from a dependency perspective, but it's annoying to do, introduces new
>>error handling cases in the application, and I suspect often upstream
>>will flatly refuse to take such a patch.

> Unless I have misunderstood, I think you may have missed another option:

> 4. Let the leaf application declare the appropriate dependency on the
>daemon, because the application writer/packager is in the best position
>to know how important the functionality provided by the daemon is to the
>application. This could be considered to be option 2b, and a "suggests"
>dependency of the library on the daemon may still be appropriate.

I was thinking of this as a special case of 2, but yes, it's a
sufficiently common special case that it's worth calling out on its own.

I'm not sure that this whole discussion belongs in Policy because it's
very hard to make policy recommendations here without a lot of
case-specific details, but a section in the Developers Guide or some
similar resource about how to think about these cases seems like it might
be useful.  It does come up pretty regularly.

-- 
Russ Allbery (r...@debian.org)  

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

[Roger Lynn]

On 15/01/2024 18:00, Russ Allbery wrote:
> When you have the case of an application that optionally wants to do foo,
> a shared library that acts as a client, and a daemon that does foo, there
> are three options:
> 
> 1. Always install the shared library and daemon even though it's an
>optional feature, because the shared library is a link dependency for
>the application and the shared library viewed in isolation does require
>the daemon be running to do anything useful.
> 
> 2. Weaken the dependency between the shared library and the daemon so that
>the shared library can be installed without the daemon even though it's
>objectively useless in that situation because it's the easiest and
>least annoying way to let the application be installed without the
>daemon, and that's the goal.  The shared library is usually tiny and
>causes no problems by being installed; it just doesn't work.
> 
> 3. Weaken the dependency between the application and the shared library,
>which means the application has to dynamically load the shared library
>rather than just link with it.  This is in some ways the most "correct"
>from a dependency perspective, but it's annoying to do, introduces new
>error handling cases in the application, and I suspect often upstream
>will flatly refuse to take such a patch.

Unless I have misunderstood, I think you may have missed another option:

4. Let the leaf application declare the appropriate dependency on the
   daemon, because the application writer/packager is in the best position
   to know how important the functionality provided by the daemon is to the
   application. This could be considered to be option 2b, and a "suggests"
   dependency of the library on the daemon may still be appropriate.

As a user, I don't like option 1, and think it could result in packagers
being asked to provide heavy and light versions of their applications with
all their optional libraries linked or not. When installing new packages I
tend to assume that applications will have some sort of dependency on
daemons which are important to them.

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

[Simon McVittie]

On Mon, 15 Jan 2024 at 19:59:22 +0100, Johannes Schauer Marin Rodrigues wrote:
> 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

Yes they do, you have rediscovered
https://lists.debian.org/debian-devel/2019/08/msg00278.html as mentioned
earlier in the thread.

Back in 2019, I felt that the project was demanding that I must find a way
to break that dependency chain, so I proposed a debhelper patch, which
was rejected. If this dependency chain is particularly objectionable to
you, please consider revisiting #934893 and advocating it better than I
was able to. One of the problems with feeling obliged to do work that I,
personally, don't believe is the right thing is that I'm never going to be
very effective at convincing others that they should accept that change.

smcv

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

[Johannes Schauer Marin Rodrigues]

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

signature.asc
Description: signature

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

[Simon McVittie]

On Mon, 15 Jan 2024 at 09:58:46 -0800, Russ Allbery wrote:
> "Theodore Ts'o"  writes:
> > I'll argue that best practice is that upstream [should] make the shared
> > library useful *without* the daemon

Is the argument here that any design that separates into clients and a
non-optional server (for example to do privilege separation, or to mediate
indirect access to a non-shareable resource) is fundamentally flawed?
If yes, then goodbye to task-desktop, because X11 and Wayland are both
among the protocols that work like that.

I would personally like to see *more* privilege separation across IPC
boundaries rather than less, if that can reduce the total attack surface
of the setuid/setcap executables in the trusted computing base. I'm sure
you're one of a few developers in Debian who can successfully navigate
the hazards involved in writing a safe setuid executable without making
security-sensitive mistakes, but that puts you in a small group whose
limited time doesn't scale well.

On Mon, 15 Jan 2024 at 09:58:46 -0800, Russ Allbery wrote:
> 2. Weaken the dependency between the shared library and the daemon so that
>the shared library can be installed without the daemon even though it's
>objectively useless in that situation because it's the easiest and
>least annoying way to let the application be installed without the
>daemon, and that's the goal.

This is what we have typically done for sound servers (PulseAudio,
Pipewire, Jack and friends), for X11, for Wayland, and for optional uses
of D-Bus, among other frameworks where the separation into server and
client is sort of the point.

For uses of D-Bus that are important or essential to the application,
typically it is the application rather than the client library that
has a weak or strong dependency on {default-,}dbus-{system,session}-bus
and the appropriate service to talk to.

That works fine if the service we're talking to is something that
we expect "most" desktop environments to have pulled in somehow,
but the cost of that approach is that every component needs a plan
for how to cope with the server not being there. For instance, for
password storage (gnome-keyring, kwallet and other such things), the
fallback will typically be to write the password to a flat file that
will not be encrypted-at-rest (unless the sysadmin has taken steps to
use system-level encryption), which is a perfectly viable implementation
but seems non-ideal as a default.

smcv

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

[Gioele Barabucci]

On 15/01/24 18:58, Russ Allbery wrote:

When you have the case of an application that optionally wants to do foo,
a shared library that acts as a client, and a daemon that does foo, there
are three options:


From the point of view a Debian package there are four options: 
Depends:, Recommends:, Suggests:, Enhances:, [nothing].


Perhaps a fifth category is needed for this 
shared-library-that-talks-to-a-deamon scenarion.


Or the whole D/R/S system could be changed to be more explicit about why 
a package Depends: or Recommends: another one:


* LinksToLibrary (Depends:)
* UsesProgram (Depends:)
* UsesProgramInMaintscript (Pre-Depends:)
* TalksToDaemon (Depends:)
* TalksToDaemonIfAvailable (Recommends:/Suggests:)
* LoadsAtRuntimeIfAvailable (Recommends:/Suggests:)
* IsPluginFor (Enhances:)

Regards,

--
Gioele Barabucci

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

[Russ Allbery]

"Theodore Ts'o"  writes:

> I'll argue that best practice is that upstream show make the shared
> library useful *without* the daemon, but if the daemon is present,
> perhaps the shared library can do a better job.

Eh, I think this too depends on precisely what the shared library is for.
The obvious example of where this doesn't work is when the shared library
is a client for a local system service, and its entire point is to
dispatch calls to that service, but the library and service combined
implement an optional feature in some of the programs linked to it.

I think that's a relatively common case and the sort of case that provokes
most of the desire to not make shared libraries have hard dependencies on
their services.  There are a bunch of services that do not support (and
often would never reasonably support) network connections to their
underlying services.  An obvious example is a library and service pair
that represents a way to manage privilege escalation with isolation on the
local system.  You cannot make the shared library useful without the
daemon because the entire point of the shared library and daemon pair is
to not give those permissions to the process containing the shared
library.

When you have the case of an application that optionally wants to do foo,
a shared library that acts as a client, and a daemon that does foo, there
are three options:

1. Always install the shared library and daemon even though it's an
   optional feature, because the shared library is a link dependency for
   the application and the shared library viewed in isolation does require
   the daemon be running to do anything useful.

2. Weaken the dependency between the shared library and the daemon so that
   the shared library can be installed without the daemon even though it's
   objectively useless in that situation because it's the easiest and
   least annoying way to let the application be installed without the
   daemon, and that's the goal.  The shared library is usually tiny and
   causes no problems by being installed; it just doesn't work.

3. Weaken the dependency between the application and the shared library,
   which means the application has to dynamically load the shared library
   rather than just link with it.  This is in some ways the most "correct"
   from a dependency perspective, but it's annoying to do, introduces new
   error handling cases in the application, and I suspect often upstream
   will flatly refuse to take such a patch.

We do 2 a lot because it's pragmatic and it doesn't really cause any
practical problems, even though it technically means that we're not
properly representing the dependencies of the shared library.  We in
general try not to do 1 for reasons that I think are sound.  Minimizing
the footprint of applications for people who don't want optional features
is something that I personally value a lot in Debian.

-- 
Russ Allbery (r...@debian.org)  

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

[Theodore Ts'o]

On Mon, Jan 08, 2024 at 11:18:09AM +, Simon McVittie wrote:
> On Mon, 08 Jan 2024 at 08:21:08 -, Sune Vuorela wrote:
> > Maybe the question is also a bit .. "it depends".
> ...
> > So that users actually likely get a system that works?
> 
> I think the fact that we argue about this every few years, with no simple
> conclusion, is adequate evidence that the answer is "it depends". We're
> balancing two competing factors: "make the system work by default" implies
> that *something* needs to be responsible for pulling in required services
> at least some of the time, while "make the system flexible" implies that
> we should not be pulling in all of the services all of the time.

I'll argue that best practice is that upstream show make the shared
library useful *without* the daemon, but if the daemon is present,
perhaps the shared library can do a better job.

For example, when I implemented libuuid, if you want to create a huge
number of UUID's very quickly, because you're a large enterprise
resource planning application, the the uuidd daemon will allow
multiple processes to request "chunks" of UUID space, and create
unique UUID's without having to having to go through some kind of
locking protocol using a single shared state file.

So libuuid works just fine without uuidd, but if you are populating a
large ERP system, then you very much will want uuidd to be installed.
So in that case, you can make the dependency relationship be either
suggests or recommends, instead of a hard dependency.

Of course, that's an upstream design consideration, and not all
upstreams are so forward looking... in their design.

> 
> Meanwhile, some distributions are more opinionated than Debian,
> have chosen a distro-wide preferred implementation for each swappable
> component, and make it quite difficult to exclude those components or
> swap them for alternatives. We probably don't want to do that either.

Well, right.  And if the distribution's primary market is enterprise
customers, such that using an Enterprise Resource Planning system is
highly likely (even if said ERP is proprietary softare sold by a very
large German company), you might decide that it's worthwhile to
install uuidd by default, especially since it's a relativelty small
daemon.  But if you're a distribution that thinks that every last
kilobyte matters, because you might be used in a docker context (for
example), then you mnight want to make different choices.

Cheers,

- Ted

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

[Jeremy Stanley]

On 2024-01-08 09:57:16 +0100 (+0100), Dylan Aïssi wrote:
[...]
> Please don't do that. At least one pipewire module depends on libpulse0
> (libpipewire-module-pulse-tunnel from the libpipewire-0.3-modules package).
> But, pulseaudio is useless in this case that means it will be unnecessarily
> pulled.

Worse than useless, pipewire-audio declares a conflict with the
pulseaudio (daemon) package since 0.3.60-1 (so including bookworm).
I've already encountered a third-party package that declares a
depends on pulseaudio and is uninstallable for that reason, or would
require uninstalling the pipewire audio stack at least.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

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

[Dale Richards]

On 07/01/2024 19:39, Ansgar wrote:

> I would like to extend Debian Policy on libraries depending on services
> (daemons) that they can speak to.

Generally speaking, if an application is using a client-server model and 
there's no technical requirement for the client and server to be running on the 
same machine, the client package should absolutely *not* depend on the server 
package.

As an example, if I install some PostgreSQL libraries on my laptop so I can 
manage a bunch of PostgreSQL servers I maintain, I clearly don't need or want a 
full PostgreSQL server installed on my laptop.

This also holds true for audio daemons like PulseAudio. The server component is 
not required for the client libraries to function, so the latter should not 
depend on the former. The argument is less clear in this case since the 
majority of users will likely be running client and server on the same box, but 
I believe the logic is the same. A package's "Depends" field is for installing 
packages that are _required_ in order for the requested package to function, 
and shouldn't be used to provide user convenience based on an assumed use case. 
That's really what "Suggests" is for. If we have high confidence that another 
package is required for a dominant use case we could go as far as "Recommends", 
but we should only use "Depends" for additional packages required for *all* of 
a package's use cases.

Best regards,

Dale Richards

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

[Simon McVittie]

On Mon, 08 Jan 2024 at 08:21:08 -, Sune Vuorela wrote:
> Maybe the question is also a bit .. "it depends".
...
> So that users actually likely get a system that works?

I think the fact that we argue about this every few years, with no simple
conclusion, is adequate evidence that the answer is "it depends". We're
balancing two competing factors: "make the system work by default" implies
that *something* needs to be responsible for pulling in required services
at least some of the time, while "make the system flexible" implies that
we should not be pulling in all of the services all of the time.

In some of the distributions we are competing with, the default answer
would be "install no services, the user is expected to know what they are
doing". I think that would be doing our users a disservice: we cannot
expect new users of Linux to "just know" that in practice, to get what
a new user would consider to be a working desktop system, they are going
to need dbus-daemon (or dbus-broker), Pipewire (or PulseAudio or JACK or
something), logind (or elogind), xdg-desktop-portal, an implementation
of o.fd.Notifications, an implementation of o.fd.Secrets and so on.

Meanwhile, some distributions are more opinionated than Debian,
have chosen a distro-wide preferred implementation for each swappable
component, and make it quite difficult to exclude those components or
swap them for alternatives. We probably don't want to do that either.

See also the thread starting at
https://lists.debian.org/debian-devel/2019/08/msg00278.html
and in particular my reply
https://lists.debian.org/debian-devel/2019/08/msg00291.html, where our
choices are "pull in a dependency" or "user configuration changes are
not saved". In response to that thread, I proposed a debhelper patch in
#934893 to make it possible to break the dependency chain in what I felt
would be the least inappropriate place, and that change was wontfix'd.

If libraries that pull in services are considered to be a serious problem,
one option would be for "the big desktop environments" (GNOME, KDE,
etc.) to have Depends or Recommends on a reasonable set of services
that users of those environments will typically want, and then drop
dependencies on those services from lower down the stack. However,
I suspect that the result of that action would be RC bug reports from
users who have pieced together their own unique desktop environment
from individual components (or just installed the desktop environment
without Recommends), installed one leaf application from GNOME or KDE, and
found that the application does not work correctly (or at all) without a
service that this particular user's customized desktop environment does
not depend on.

We cannot have a policy that libraries must not depend on the daemons
that are sometimes necessary to make them work as designed, but at the
same time have a policy that says missing dependencies are a RC bug that
maintainers are expected to drop everything to fix immediately. Demanding
that maintainers do impossible things will not give us better software,
it will just give us burned-out maintainers.

smcv

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

[Dylan Aïssi]

Hi,

Le dim. 7 janv. 2024 à 20:40, Ansgar  a écrit :
>
> 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?

Please don't do that. At least one pipewire module depends on libpulse0
(libpipewire-module-pulse-tunnel from the libpipewire-0.3-modules package).
But, pulseaudio is useless in this case that means it will be unnecessarily
pulled.

Best regards,
Dylan

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

[Sune Vuorela]

On 2024-01-07, Ansgar  wrote:
> 1. libpulse0 & friends
> --

> 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).

I'm a bit .. it depends. But it might end up being delegated to the
applications to do it manually maybe.

Assuming an audio providing program (netradio streamer or something)
that just does pulseaudio. No backends. no configuration. Just pulse.

I would not expect users to figure out that a Suggests: pulseaudio was
the missing bit needed to get the application to actually work.

On the other hand

> 3. The general case
> ---

I'm currently investigating an upstream bug report from a sister
distribution.

A document reader links thru various intermediate steps to libspeech2, a
library from src:speech-dispatcher to talk to speech-dispatcher daemon
to do text-to-speech. And libspeech2 (at least thru the intermediates)
ends up not giving me an easy failure to act upon.

How do the distribution maintainer of the document reader ensure that 
the users know that they need speech-dispatcher around for that to work?


Maybe the question is also a bit .. "it depends". 
Assuming 10 different sound servers, one might be the one we as a
distribution considers the default. Maybe the default one should have
libfoo: Recommends: foo.
and the non-defaults should have
libbar: Suggests: bar

So that users actually likely get a system that works?

I guess it is a tradeoff between extra-cruft-on-systems and
likely-that-systems-work, and we need to draw a line somewhere.

I might also be slightly biased towards adding slightly extra cruft on
systems to ensure they work because of the package collection I'm
involved in (KDE and friends) as opposed to people maintaining packages
mostly used by server administrators, maybe even container-heavy server
administrators.

/Sune

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

[Mo Zhou]

On 1/7/24 15:36, Jonas Smedegaard wrote:

Quoting Ansgar (2024-01-07 20:39:57)

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, ...).

I thought this was already in policy.  If not then yes, certainly makes
sense to add that!
Regarding "I thought ... if not ...", please allow me to jump in and 
advertise a little bit.


$ debgpt -H -f policy_index.txt -A 'According to this table of contents, 
which part may have discussed dependency of shared objects on services 
which they can speak to?' --openai_model gpt-3.5-turbo-16k


LLM [2]> Based on the table of contents, the part that may have 
discussed the dependency of shared objects on services they can speak to 
is section 8.6, titled "Dependencies between the library and other 
packages." This section covers the dependencies between the packages of 
the same library and the dependencies between the library and other 
packages. It may include information on how shared objects can 
communicate with services they depend on.



$ debgpt -H --policy 8.6 -A 'does this section discuss that shared 
object packages should generally *NOT* Depends: or Recommends: services 
which they speak to?' --openai_model gpt-3.5-turbo-16k


LLM [2]> No, this section does not discuss whether shared object 
packages should or should not have dependencies on services they speak 
to. Section 8.6 of the Debian Policy specifically focuses on 
dependencies between the library and other packages. It explains the 
mechanisms of using "symbols" files or "shlibs" files to determine the 
required dependencies for shared libraries. It also provides guidelines 
for maintaining shared library packages and handling backward-compatible 
ABI changes.


lumin[3]> OK. Where should I add it if I would like to introduce this 
new policy?


LLM[4]> If you would like to introduce a new policy regarding shared 
object packages and their dependencies on services, you would need to 
propose the change to the Debian Policy mailing list. The mailing list 
is the appropriate forum for discussing and proposing changes to the 
Debian Policy. Once your proposal is accepted and approved by the Debian 
Policy team, it will be incorporated into the official Debian Policy 
document.


...

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

[Jonas Smedegaard]

Quoting Ansgar (2024-01-07 20:39:57)
> 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, ...).

I thought this was already in policy.  If not then yes, certainly makes
sense to add that!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

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

[Scott Kitterman]

On January 7, 2024 7:39:57 PM UTC, Ansgar  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