Bug#883756: dbus-user-session: blocks upgrades; installing dbus-user-session yields a change of the init system

[Simon McVittie]

Control: tags 883756 + wontfix

On Thu, 07 Dec 2017 at 10:54:07 +0100, Vincent Lefevre wrote:
> If I do "apt upgrade -s"[*] on some old machine, I can see that
> pulseaudio is kept back. This is because pulseaudio now recommends
> dbus-user-session
> 
> [*] A dist-upgrade is not a solution since it will change the init
> system.

This is not a bug in dbus-user-session, which is working as designed.
It genuinely does need systemd. Alternatives exist for non-systemd users.
It could be argued to be a bug in pulseaudio, but I think it's acceptable
for configurations that are not recommended by the package's maintainer
to require breaking Recommends (that's sort of the point).

You have (apparently deliberately) chosen to not use Debian's default
init system, which means you have one of the "unusual installations"
mentioned in "packages that would be found together with this one in
all but unusual installations" (the Policy definition of Recommends).
I would recommend using the default init system and the Recommends of
most or all packages, but since you've already chosen a non-default
init system, I assume you're not going to want to take that advice.

If you are confident that you can make this unusual installation work
to your satisfaction, please instruct your package manager to break the
Recommends and install pulseaudio anyway. You can expect to experience
degraded functionality, which is not necessarily considered a bug (after
all, if the systemd code path didn't work better than the non-systemd
code path in at least some situations, then there would be no point in
having it).

If you are breaking Recommends and otherwise exploring non-default code
paths, you might prefer to use an interactive TUI like aptitude to do
your upgrades, or learn enough of apt's CLI syntax to be able to force
it into non-default dependency resolutions (untested: something like
"apt install pulseaudio dbus-user-session- systemd-sysv-" might work,
with the trailing "-" denoting "remove or don't install").

I am not a pulseaudio expert, but from the pulseaudio commit
https://anonscm.debian.org/cgit/pkg-pulseaudio/pulseaudio.git/commit/?id=5c1ef223ab11096aa7dfcbb9addf5513aaedefa9
it looks as though one form of degraded functionality that you will
experience might be: pulseaudio will not start automatically on-demand,
unless you edit /etc/pulse/client.conf.d/00-disable-autospawn.conf to
re-enable the "autospawn" mechanism, or take some other steps to have
a pulseaudio process run before you need it.

Another form of degraded functionality might be that programs might not
be able to control pulseaudio using D-Bus messages. (Or they might be
able to control it with D-Bus messages after all, depending how
pulseaudio was started, how dbus-daemon was started, and whether
either, neither or both of those is involved in an X11 session -
starting services without using a service manager tends to be
non-deterministic, and these services are no exception.)

Mechanisms of the form "run $something, unless it is already running,
without help from a service manager" have a tendency to be complicated and
fragile, and result in the daemon being a child process of an arbitrary
one of its clients, inheriting the unpredictable execution environment
of that client; so I can understand why the Debian maintainers of
pulseaudio would want those mechanisms to only be used by people who
have deliberately chosen a non-standard system configuration and are
hopefully able to debug the result. dbus-x11 has traditionally had all
the same problems. On systemd systems, dbus-user-session avoids them by
using the systemd service manager to manage services.

In principle the pulseaudio maintainers could have split
out /usr/lib/systemd/user/pulseaudio.{service,socket} and
/etc/pulse/client.conf.d/00-disable-autospawn.conf into a separate
pulseaudio-user-session package that Depends on dbus-user-session,
Recommends systemd-sysv and is recommended by pulseaudio, but I can see
why they wouldn't want that extra complexity, and it wouldn't actually
have made your situation any better (you'd be breaking a Recommends
either way).

> Note: systemd-shim should emulate systemd features that are needed
> for some services. So, either something is missing in systemd-shim
> or the Recommends on systemd-sysv is really bogus.

systemd-shim might have been valuable as a transitional mechanism, but
I don't think it is long-term supportable. Its Debian maintainers seem
to agree (they have orphaned it).

The answer to your dichotomy is that something (in fact, a lot) is missing
in systemd-shim. systemd-shim emulates just enough of systemd-as-pid-1
to be able to run systemd-logind, which is systemd's replacement for the
deprecated ConsoleKit (and some system services that "depend on systemd"
really only depend on systemd-logind, so that has historically been an
interesting thing to provide).

It is very much not a full implementation of systemd's functionality
and APIs - if you want one of those, boot your system with systemd. In
particular, systemd-shim doesn't run a `systemd --user` instance for
each uid that is currently logged in (see #756247), and if it did I would
expect its target audience to complain rather vehemently. `systemd --user`
is the same executable as systemd-as-pid-1, but running in a different
mode, without privileges, and managing a user session instead of the
system boot.

dbus-user-session genuinely does need a working `systemd --user`[1]:
its purpose is to delegate dbus-daemon startup, together with a lot of
the service management for activatable D-Bus services, to
`systemd --user` (which also implies there is at most one
`dbus-daemon --session` per uid, not the traditional one per X11
session). In most distributions, the equivalent of dbus-user-session is
either mandatory (if the distro boots with systemd) or not available (if
the distro boots with something else). It's separate in Debian because
we have some level of support for both configurations, and making it
separate allows packages to have a hard dependency on dbus-user-session
as a way to declare that they can't work correctly without it.

dbus-user-session should in principle have a Depends on systemd-sysv
rather than its current Recommends, but I didn't do that because a user
of systemd-as-pid-1 could in principle have systemd but not systemd-sysv
and be booting with init=/bin/systemd.

The dependency tree, which can't all be expressed in Debian package
relationships, goes something like this, with arrows pointing towards
dependencies:

    systemd as pid 1                 systemd-shim + non-systemd pid 1
          ^       ^                            ^
          |       \-----------------------\    |
          |                               | OR |
    systemd --user works ------> libpam_systemd and systemd-logind
          ^                                 ^
          |     /---------------------------/
          | AND |
    dbus-user-session      dbus-x11
          ^                    ^
          \-------\    /-------/
                  | OR |
           dbus-session-bus (#833401: at least X11 sessions,
           and maybe all sessions, have dbus-daemon --session)

If Debian eventually drops support for non-systemd boot, then I could
imagine also eventually dropping support for non-dbus-user-session
session buses, but neither seems likely to happen soon. A more likely
medium-term change might be for systemd-shim to go away, which would
mean that desktop systems effectively require systemd but minimal servers
and the installer don't.

Regards,
    smcv

[1] Well I suppose strictly speaking it needs something that, when given
    the files in dbus-user-session.deb as inputs, behaves a lot like
    `systemd --user`; and if someone wanted to write an alternative
    per-user service manager with compatible behaviour and arrange for it
    to be started at the appropriate times, dbus-user-session could have
    an alternative dependency on that. But I don't see that happening
    any time soon, because the people who dislike systemd dislike it
    for its design, which presumably means they have little interest in
    writing a service manager with a compatible design.