Bug#1061297: libelogind0: does not implement all ABI required by important packages like procps

Simon McVittie smcv at debian.org
Mon Jan 22 16:22:39 GMT 2024

On Mon, 22 Jan 2024 at 15:10:14 +0000, Mark Hindley wrote:
> On Mon, Jan 22, 2024 at 10:47:08AM +0000, Simon McVittie wrote:
> > Expected result: libelogind0 is a drop-in replacement for libsystemd0 in
> > this scenario,
> This used to be the case, but in sid/trixie to resolve[1] the lag in upstream
> elogind releases[2], we now have a patch for elogind which enables it to use
> libsystemd0 directly[3].  That means that the expected dependencies are now
>  libpam-elogind -> elogind -> libsystemd0
> with procps installable and libelogind0 not installed.
> So, I am curious why libelogind0 was being installed in your VM. Did you request
> it specifically?

I'm not sure what is going on here, to be honest. Perhaps I did install
libelogind0 specifically because that had been necessary in the past?
My sidegrade from systemd to sysvinit went poorly because systemd
(IMO quite reasonably) doesn't want to be removed while it's still
the implementation of the running pid 1, so probably I did a wrong
workaround somewhere.

Retrying this in a fresh VM, with the steps that I should have taken,
if I'd known:

* Start from a virtual machine image produced by autopkgtest-virt-qemu,
  with systemd-sysv (any relatively minimal image would probably be OK)

* apt install sysvinit-core
  (removes libpam-systemd)

* reboot
  (init is now sysvinit)

* apt purge systemd
  (installs systemd-standalone-sysusers instead)

* apt install elogind libpam-elogind

* reboot
  (possibly unnecessary but seems safer)

* apt install xdm xorg openbox
  (This tried to remove sysvinit-core/elogind and reinstate systemd-sysv,
  which would defeat the purpose of this test, so I cancelled.)

* apt install xdm xorg openbox systemd-sysv-
  (This still tried to remove elogind, so I cancelled.)

* apt install xdm xorg openbox systemd-sysv- elogind

I don't have any particular interest in non-systemd init systems, so you
would know better than me how to proceed from there, and maybe how to make
installing a small graphical desktop less likely to swap back to systemd.

This is prompted by
https://lists.debian.org/debian-devel/2024/01/msg00268.html where a user
seems to be making life hard for themselves by choosing to use a
non-default init system, on a -ports architecture that reached EOL
in 2018 and only exists as a version of unstable, on 20 year old
hardware. unstable can work but should be done with caution because
large chunks of it are sometimes uninstallable; non-default init has
similar caveats; and -ports has similar caveats at the best of times;
so it isn't surprising if combining the three will sometimes propose
removal of important packages.

> Bin:libelogind0 is still built by src:elogind and available in
> the archive. I hesitated to remove it before being certain that the elogind
> cgroups patch to use libsystemd0 was reliable. But maybe libelogind0 should
> become a dependency package to smooth upgrades?

If you are intentionally replacing x by y on all end-user systems that
have it, and y provides all the "API" of x, then I think it's nearly
always correct and necessary for x to become a transitional package that
depends on y. When we try to shortcut around that, the result is frequently
a need to fix it up during the freeze after receiving upgrade reports.

I see that elogind Conflicts with libelogind0. On existing systems with
both elogind and libelogind0, this is going to leave apt taking a guess
at which one is more important to you - keeping elogind, or keeping
libelogind0 - and it will at least sometimes produce the wrong answer
(especially because few packages depend on elogind, but lots of packages
depend on libsystemd0, which on existing elogind-based systems is provided
by libelogind0, so libelogind0 will tend to have a very high "score").

I think this would go better with a transitional package to migrate
to libsystemd. elogind could have a Breaks: libelogind0
(<< first transitional version), or something?


More information about the Debian-init-diversity mailing list