elogind plan

[Adam Borowski]

On Mon, Dec 03, 2018 at 12:28:26PM +0000, Simon McVittie wrote:
> 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.

Point taken.  You might or might not look at the middle section; I'm
responding to it mostly for the sake of the list.

For your convenience, I marked pieces you might want to skip with a line.

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

It's the very thing you describe below, in the indented section.  This is
what I'd want for today, separating it from issues that need more thought.

---------------------------------------------------------------------------

> 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

I'm afraid that'd be needed to handle upgrades/switching.  My idea would be
to have both init scripts check what's pid 1:
* if systemd, them systemd-logind would start, elogind would not
* if not systemd, systemd-logind would refuse to start
To reduce your effort, the systemd side can be implemented simply by
providing a .service but no init script.

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

What we want is to install libpam-systemd if there's systemd, libpam-elogind
otherwise.  Having apt insist on switching inits when you install a random
GUI package is not fun.

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

That's not a requirement here: the TC has just decreed that
derivative-specific patch series are disallowed, thus Devuan would carry a
patch, with no code on Debian side.

So this part needs no thought on your side.

> * where possible, those dependencies are written the same in Debian and
>   Devuan, via virtual packages or metapackages
>   - rationale: fewer packages to modify

Can be nice, yeah.  Not a strong requirement.

> * packages that specifically require systemd init + systemd-logind cannot
>   be co-installed with elogind
>   - rationale: if they were, they would fail to work

Right.  We want to reduce those as much as possible.

> * there is no binary linked to both libsystemd and libelogind
>   - rationale: they can't both define sd_pid_get_session()

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

* it must be possible to switch from systemd to elogind (current d-i can
  install only the former!) -- or, Cthulhu forbid, the other way!  --
  without first removing every GUI package, rebooting, then installing the
  world again.  Even if there's temporary disruption (ie, require immediate
  reboot _after_ apt finishes), unrelated packages at a long end of a
  dependency chain stay.

---------------------------------------------------------------------------

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

Yeah.

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

Besides the convoluted case of policykit-1, patches in my pile were
restricted to:
* libpam-systemd -> default-logind | logind (possibly with arch annotations
  or consolekit logic)
* removal of spurious dependencies on systemd or systemd-shim | systemd-sysv
  (each of those required testing -- not all such dependencies are spurious!)
* [linux-any] confusion

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

I don't recall any problems with dbus; it seems to work fine for me with the
libpam-elogind-compat workaround.  Of course I use dbus-x11.

policykit-1 is the only package so far identified to require to be built
twice, but the code _looks_ like it could be changed so the determination
happens at runtime.  If we manage that, the two-binary issue would be
avoided.  But, either way it won't affect src:systemd.

So -- do you see any immediate problems with the provides plan?  I'll file a
pull request shortly...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄⠀⠀⠀⠀ to the city of his birth to die.