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 (Success.) 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? smcv
