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. _______________________________________________ pkg-pulseaudio-devel mailing list pkg-pulseaudio-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-pulseaudio-devel