elogind plan

[Simon McVittie]

On Mon, 03 Dec 2018 at 10:38:49 +0100, Adam Borowski wrote:
> Simon: could you please tell us if you still think your old idea is good?

Sorry, I don't have the bandwidth to put any significant thought into
designing a coherent system with a choice between systemd-logind and
elogind. I'm happy with systemd-logind (for both my personal systems
and my work), so having the choice is not something that interests me.

If you want an informed opinion on whether my old idea was good, you'll
have to remind me what my old idea was (or perhaps more accurately, your
plan that is based on or perhaps even identical to my old idea).

Having some design goals written down would perhaps also be useful,
such as:

* systemd-logind and elogind cannot both be installed at the same time
  - rationale: unnecessary complexity to support
* packages that can work with either systemd-logind or elogind have
  dependencies that end up installing systemd-logind on Debian systems,
  in the absence of sysadmin action to get elogind instead
  - rationale: it's the Debian default
* packages that can work with either systemd-logind or elogind have
  dependencies that end up installing elogind on Devuan systems
  - rationale: it's the Devuan default
* where possible, those dependencies are written the same in Debian and
  Devuan, via virtual packages or metapackages
  - rationale: fewer packages to modify
* packages that specifically require systemd init + systemd-logind cannot
  be co-installed with elogind
  - rationale: if they were, they would fail to work
* there is no binary linked to both libsystemd and libelogind
  - rationale: they can't both define sd_pid_get_session()

(If you have more design principles to add, or reasons why one of those
needs to be discarded, then that's fine; the useful part is that they're
written down, and any that are contentious or debatable have rationale.)

> In January, I prepared a set of patches for all packages with a
> libpam-systemd dependency

If you can summarize what those patches are, in terms of equivalence
classes of packages (with their members), that would be helpful.
Perhaps something like this? Please ignore the actual technical detail
here, because I'm completely making it up (and some of it is deliberately
not true to make that point), but this *level of* technical detail would
be useful:

    """
    Packages that need to register their login sessions with logind
    (gdm3, lightdm, openssh-server):
    - remove libpam-systemd dependency
    - add default-logind | logind dependency

    Packages that need to determine which login session a process belongs
    to (policykit-1, dbus, procps):
    - remove libpam-systemd dependency
    - add default-logind | logind dependency
    - keep libsystemd dependency for its client APIs

    Packages that need to call logind D-Bus APIs to reboot, suspend etc.
    (gdm3, lightdm, gnome-settings-daemon):
    - remove libpam-systemd dependency
    - add default-logind | logind dependency
    - keep libsystemd dependency (if present) for its client APIs

    Packages that rely on running systemd --user units (dbus-user-session,
    gnome-session, gnupg):
    - unchanged, elogind is not supported here
    """

For packages with non-trivial changes the actual patches would also be
interesting.

With my dbus upstream hat on I've been sent a patch from Gentoo that adds
support for compiling dbus against libelogind instead of libsystemd. This
sort of compile-time selection is obviously fine for Gentoo, where each
user creates their own somewhat coherent binary distribution via their
choice of USE flags, or for a derivative like Devuan, where the choice
has been made distro-wide; but I don't think it would be sustainable for
Debian to compile all libsystemd-using binary packages twice (e.g. as
dbus and dbus-elogind, or policykit-1 and policykit-1-elogind) so I hope
the plan for this is something else.

    smcv