[Pkg-utopia-maintainers] Bug#883756: dbus-user-session: blocks upgrades; installing dbus-user-session yields a change of the init system

[Simon McVittie]

(Please keep the PulseAudio maintainers in Cc: if this is a bug at all,
then it's in pulseaudio, not dbus. But I don't think it's a bug.)

On Thu, 07 Dec 2017 at 15:08:20 +0100, Vincent Lefevre wrote:
> On 2017-12-07 11:57:05 +0000, Debian Bug Tracking System wrote:
> > 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).

During the wheezy-to-jessie upgrade, the sysvinit "real" binary package
from wheezy was replaced by a transitional package that depended on
systemd-sysv|sysvinit-core. You made a choice not to follow the project's
default at that point, by installing the non-default/non-preferred
alternative, sysvinit-core, rather than the default/preferred alternative,
systemd-sysv.

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

I can see why you'd think so, but no. pulseaudio is not an ordinary
D-Bus client (like evince) or an ordinary D-Bus service (like
gnome-terminal-server), because it gets started "eagerly" for its
side-effects, not just on-demand.

In recent pulseaudio versions on systemd systems, the pulseaudio
service is started by `systemd --user`. This is outside the scope of the
per-X11-session instance of `dbus-daemon --session` created by dbus-x11
(one pulseaudio per uid, not one per X11 session), so the pulseaudio
service would have no DBUS_SESSION_BUS_ADDRESS and no D-Bus session
bus connection, making it impossible for session clients to communicate
with it via D-Bus (which I assume some of them want to do). With
dbus-user-session, the scope of the session bus expands to be the same
as the scope of `systemd --user` and pulseaudio, so pulseaudio can use
it again.

Historically, the scope of the pulseaudio instance was <= the scope
of the X11 session, which was <= the scope of the `dbus-daemon --session`,
so we didn't have this problem - except when not using X11, in which
case it would just not work.

The recommendation should ideally be something like
"dbus-user-session | NOT(booted using systemd)", but we don't have the
syntax to express that.

pulseaudio having "Recommends: dbus-user-session | sysvinit-core" is
probably the closest it could get. However, pulseaudio has degraded
functionality on systems without `systemd --user` anyway (to have its
historical functionality back, it would need reconfiguration to turn
autostarting back on), so it might not be wise to give it a Recommends
that appears to advocate use with sysvinit.

Arguably pulseaudio's Recommends on libpam-systemd (added for #882142)
was insufficient and should have been
"Recommends: systemd-sysv, libpam-systemd", because that's what you need
to have a `systemd --user`. That way you'd still find yourself breaking
a Recommends, but I think that's a reasonable representation of how well
pulseaudio-as-currently-packaged is supported on this particular system.

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

If you're in an unusual/non-default situation, and you're having to
intervene to make things work as expected (for example by deleting or
editing /etc/pulse/client.conf.d/00-disable-autospawn.conf) then I think
an unsatisfied Recommends is a reasonable representation of that.

(I have about 100 unsatisfied Recommends on my development laptop and
haven't found it to be a significant problem, although admittedly
that's mostly because check-all-the-things and diffoscope are rather
enthusiastic with their use of Recommends.)

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

I hope my explanation made it clear why it's the
pulseaudio → dbus-user-session recommendation that would have to break.

    smcv