Re: Policy: should libraries depend on services (daemons) that they can speak to?
On Mon, 08 Jan 2024 at 08:21:08 -0000, 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
Reply to: