Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
On Sun, 01 Dec 2019 at 11:13:46 -0800, Russ Allbery wrote:
> Simon Richter <sjr@debian.org> writes:
> > Right, but the dependency chain is there to make sure the package is
> > usable on systemd systems
>
> My recollection is that these dependencies are mostly about either making
> sure user sessions are available or that D-Bus is available, right? (I'm
> fairly sure about user sessions and less sure about D-Bus.)
"Making sure D-Bus is available" is not particularly meaningful, because
the D-Bus system and session buses are distinct. Depending on the package
in question, it might want one or more of:
* the D-Bus system bus is available at all times (except early boot)
- it's a fairly straightforward system service
- depend on dbus (one day I might break this out into a dbus-system-bus
package, which at the moment is a Provides in dbus)
- any init system can work
* the D-Bus session bus is available in at least X11 login sessions
- it's a per-user or per-X11-display service
- depend on default-dbus-session-bus | dbus-session-bus
- any init system is fine, *if* you use dbus-x11 to implement
dbus-session-bus
- the default implementation (see below) requires systemd
* the D-Bus session bus is available in all login sessions, *and* has the
semantics that it is per-uid rather than per-login-session (the "user
bus", which is "larger than" a single login session)
- it's a per-user service
- depend on dbus-user-session
- this currently requires `systemd --user`, which requires systemd
as pid 1 *and* systemd-logind (elogind is not enough) and I don't
see this changing any time soon
dbus-user-session is not, and probably will not be, usable on non-systemd
systems. If per-user service managers other than `systemd --user` exist
and can be configured to provide equivalent semantics, I'd be happy
to review the necessary integration files, but at the moment there
is no way to have the semantics represented by dbus-user-session on a
non-systemd system.
dbus-user-session is not implied by systemd, or even by systemd --user.
Some `systemd --user` services work badly, or not at all, without
dbus-user-session (represented by a Recommends or Depends on it);
but I've gone to some lengths to make sure that if systemd users who
do not rely on those services want multiple parallel X11 sessions,
each with its own per-X11-display D-Bus session bus, they can have that
(by removing dbus-user-session and installing dbus-x11).
> > It wouldn't be a problem in practice to break that dependency chain, as
> > systemd based installations tend not to be curated on a
> > package-by-package basis
It's true that non-systemd-based installations need to be curated to
remain non-systemd-based; and it's true that because systemd is the
default init, systems that accept defaults will be systemd-based and
not strongly curated; but I don't think either of those implies that
there are no strongly curated systemd-based systems.
> Is it possible to have a systemd system that doesn't have these
> properties? In other words, do these dependencies only matter with other
> init systems, or do they also matter in container scenarios?
These categories exist:
* No service manager at all
- typical for Docker (pid 1 is usually a simple process reaper)
- typical for chroots (pid 1 is outside the chroot)
- systemd --user isn't run
- dbus-user-session doesn't work
* Various non-systemd service managers (sysv-rc, OpenRC, etc.)
- systemd --user isn't run
- dbus-user-session doesn't work
* systemd as pid 1, but no pam_systemd
- systemd --user isn't run
- dbus-user-session doesn't work
* systemd as pid 1, and pam_systemd is used
- typical for "full" systems (bare metal, VM, lxd)
- systemd --user is run
- dbus-user-session works
I hope that clarifies the situation.
smcv
Reply to: