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:

  * Add dbus-user-session to Recommends of pulseaudio.
    Dbus usage is otherwise broken, because there is no daemon to connect to,
    and dbus does not autolaunch when there is no X11 around.
    (Closes: #883542)

The problem is that dbus-user-session recommends systemd-sysv, so
that installing it has the effect to change the init system!

The following additional packages will be installed:
  libnss-systemd systemd-sysv
The following packages will be REMOVED:
  systemd-shim sysvinit-core

Users don't generally want to change the init system chosen at install
time (this is a big change, which can break things), unless explicit
requested. Thus this Recommends should be dropped.

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.

[*] A dist-upgrade is not a solution since it will change the init
system.

Control: tags 883756 + wontfix

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

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.

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

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

[...]

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

[snipped lots of interesting information]

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.

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

Re-adding the wontfix since it did not work on -done@b.d.o
(bug 746206).

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

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

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

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

    smcv

How about a new package pulseaudio-no-systemd and a Recommends on
"dbus-user-session | pulseaudio-no-systemd"? This package would
do almost nothing. It could possibly change the configuration to
re-enable autospawn.

The very few users who boot using systemd but without systemd-sysv
would have to force an install of dbus-user-session anyway. So the
Recommends would be satisfied with just dbus-user-session for them.

I fully agree that this is an issue in pulseaudio, not in
dbus-user-session, so reassigning.

It would be weird to have two snippets installed, one that enables and
the other disables pulseaudio.

I'm not sure I fully sympathize with the want to have all recommends
fulfilled (after all, they are "weak" depends precisely to be able to
break them!). But I don't want to make it unnecessarily difficult
either. I'm open to suggestions to improve the current situation, but
they must fulfill the following properties:

1. It should use the systemd --user manager by default
1b. We should keep a single place to disable, which would be the
systemd --user manager, and thus autospawn needs to be disabled by
default.
2. This configuration should not be changed unless explicitly chosen
by the admin/user.

Yes. But shouldn't the default be no-autospawn? Then the
/etc/pulse/client.conf.d/00-disable-autospawn.conf config file
would no longer be needed, and pulseaudio-no-systemd would just
add a config file to enable autospawn.

Even though they are "weak" depends, Debian tools may assume that
they are all fulfilled. For instance, "apt-get -f install" may
install Recommends that were never asked in the first place; see
the following bug (closed without a fix):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489896

More generally, having all Recommends fulfilled and not installing
Recommends by default (--no-install-recommends / APT::Install-Recommends
set to no) do not yield issues with Debian tools, but if one chooses to
install Recommends by default and break some of them, things do not get
so well...

pulseaudio-no-systemd could also just ask the user whether he wants
to enable autospawn.

But you could also see autospawn as being the default configuration
for sysvinit (where pulseaudio-no-systemd would be installed by
default). Thus it would not really be a change.

Alternatively, couldn't the PulseAudio client library be smarter,
i.e. be able to know whether it should autospawn or not by default,
without the need of a configuration file?

(pruninc cc list since this is a regular pulseaudio bug)

This may work. Could you propose a patch for this scheme? An old patch
of mine that was ultimately not accepted upstream could serve as a
starting point:

https://lists.freedesktop.org/archives/pulseaudio-discuss/2014-November/022696.html

(Remember we need to keep autospawn by default on for nonlinux archs.

This is a bit too much magic for my taste. I'm not willing to carry a
patch like this if it is not accepted upstream first.