[Pkg-utopia-maintainers] Bug#883756: closed by Simon McVittie <smcv at debian.org> (Re: Bug#883756: dbus-user-session: blocks upgrades; installing dbus-user-session yields a change of the init system)

[Vincent Lefevre]

On 2017-12-07 11:57:05 +0000, Debian Bug Tracking System wrote:
> 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).

But Recommends cannot be broken by default (and --no-install-recommends
is too strong as this would apply to all packages). There should be
some workaround (see below).

> You have (apparently deliberately) chosen to not use Debian's default
> init system,

This is not completely true: When the machine was installed in 2010,
systemd was not Debian's default init system. I chose not to switch
because I do not want to silently break config that was done for
the init system currently used on the machine (this is not my main
machine, and I still use it mainly for old non-desktop stuff on it,
sometimes for testing regressions).

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

I'm wondering. Instead of recommending dbus-user-session, shouldn't
pulseaudio recommend "default-dbus-session-bus | dbus-session-bus"
(this is what evince does)?

> 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 was using aptitude, which signaled the broken Recommends. But I don't
want to break Recommends (the choices and consequences are not always
clear, and this can confuse future upgrades). The dependencies should
have an alternative to avoid breaking Recommends. In any case, users
of sysvinit should accept loss of functionality (actually, it would
not even be a loss compared to the past), but upgrades should remain
fine.

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

Yes, breaking Recommends, thus would not solve the problem.

[snipped lots of interesting information]
> 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.

FYI, I was wondering that if a Recommends needed to be broken, which
one should be broken: the pulseaudio → dbus-user-session one, or the
dbus-user-session → systemd-sysv one. As you see, this was not clear
without your explanations.

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

This old machine can *now* be regarded as a minimal server (even
though it wasn't in the past).

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)