Re: Should libpam-elogind Provide libpam-systemd ?
On Mon, 05 Nov 2018 at 13:32:40 +0000, Ian Jackson wrote:
> When a package does not want, specifically, this sharing, the
> dependency should be on
> default-dbus-session-bus | dbus-session-bus
This is right for packages that don't particularly care whether the
session bus is per-uid or per-login-session and want to follow the
default chosen globally for Debian, including most D-Bus session clients
and services.
> or maybe the older form which I found in some packages in sid:
> dbus-user-session | dbus-x11
> (xdg-desktop-portal-gtk).
I don't remember why I set up xdg-desktop-portal-gtk like this, tbh.
It's probably a bug. I think I probably added that dependency when
dbus-user-session wasn't yet the default/preferred form of session bus,
because xdg-desktop-portal-gtk benefitted significantly in some way
from using it.
Depends: dbus-user-session | dbus-session-bus would perhaps make sense
for packages that strongly prefer the session-bus-per-uid model but can
work either way, as a way to make it explicit that they would prefer
dbus-user-session even if that wasn't Debian's default.
Depends: dbus-user-session (with no alternative) makes sense for
packages that can only work in one-session-bus-per-uid world. Those are
systemd-specific for the forseeable future.
Recommends: dbus-user-session makes sense for packages that have
significantly degraded functionality without one-session-bus-per-uid,
but can be made to work by unusual or non-default configuration.
> The value of this feature is IMO questionable.
There are various reasonable things that you might assume can be done
with D-Bus, but that turn out not to work, or can work but only badly,
when the session bus is not shared in this way. There are also things
that can work with one bus per login session, but can't work or can't
work well with one bus per uid (most of them involve multiple parallel
graphical login sessions). Can we agree to disagree on which of those
two classes is the more important one?
I don't want this to turn into "us vs. them", and I'm trying not to get
drawn into a debate about the merits of these approaches because I can
already see how much time and motivation that will burn if it happens,
most likely leaving each of us angry with the other and without any
actually changed opinions. I've gone to some lengths to make sure that
the conceptual model implied by dbus-user-session is not mandatory in
Debian (which is why we have it as a separate package at all); it would
have made D-Bus maintenance much simpler if I'd said that from now on,
one D-Bus session per uid per machine was the only supported situation,
as it is in (for example) Fedora and Arch Linux.
> pinentry-gnome3 and pulseaudio seem wrong to me. PINs should not be
> shared between login sessions and sound control should be per-session,
> not per-uid.
First of all, these are Recommends, not Depends. If you are confident that
your use of these packages (if you even use these packages) can work
without a per-(uid,machine)-scoped D-Bus session bus, you're welcome to
not satisfy the Recommends. Not having `systemd --user` on the class of
systems that these packages target is an unusual configuration, so I
think it's reasonable for Recommends to assume it.
If we had a way to spell "Recommends: dbus-user-session if init is
systemd" or "Depends: dbus-user-session if init is systemd" then these
packages could use it, but as far as I'm aware we don't, so they can't.
The pinentry-gnome3 Recommends is because gpg-agent is shared between
login sessions, so anything that is invoked by gpg-agent had better
have all its dependencies similarly shared. pinentry-gnome3 is one of
several possible implementations of a PIN/passphrase/secret prompt; it
is implemented using D-Bus IPC (it communicates with GNOME Shell, to ask
GNOME Shell to prompt for PINs/passphrases/secrets using a system-modal
dialog). This works very poorly if the D-Bus session is shorter-lived
than the gpg-agent, because the gpg-agent receives its environment
variables on startup (including the DBUS_SESSION_BUS_ADDRESS that will
be inherited by its shorter-lived pinentry subprocesses) and does not
have a way to replace them. (#801247)
Similarly, I think pulseaudio's Recommends is because pulseaudio is
frequently a systemd user service (one per uid). One of pulseaudio's
control protocols is that it can be sent commands via D-Bus IPC, but
again, that isn't going to work if the D-Bus session bus is shorter-lived
than the pulseaudio daemon.
> I'm not sure about rygel but it doesn't seem likely to me that this
> dependency on dbus-user-session is necessary. Perhaps there is
> another way to implement this on non-systemd systems.
It's another Recommends. Rygel is a long-running per-user D-Bus service
that requires a D-Bus session bus with a scope at least as long as rygel
itself; on systemd systems, making it a `systemd --user` service is
desirable; but that user-service can't start without dbus-user-session.
This would be "Depends: dbus-user-session if init is systemd" if we had
a way to spell that in dependencies.
smcv
Reply to: