Bug#1015015: unable to upgrade due to elogind vs systemd conflict

[Craig Sanders]

On Sat, Jul 16, 2022 at 10:00:27AM +0100, Mark Hindley wrote:
> What release are you upgrading from an to?

Version of what?  There's no new version of elogind. That's kind of what my
bug report is asking for.

The machine is running sid, so this was just a routine dist-upgrade.


> On Sat, Jul 16, 2022 at 06:34:35PM +1000, Craig Sanders wrote:
>
> I can't immediately see the package that might be causing the conflict here.

A little more investigation reveals that it's udev.

udev 2.51.3-1 (Wed, 13 Jul 2022 23:05:40 +0200) now depends on 'systemd | systemd-tmpfiles'.

The previous version of udev, 251.2-7 (Tue, 28 Jun 2022 14:33:37 +0200) did NOT.

Package: udev
Version: 251.3-1
Depends: libacl1 (>= 2.2.23), libblkid1 (>= 2.37.2), libc6 (>= 2.33), libcap2 (>= 1:2.10), libkmod2 (>= 5~), libselinux1 (>= 3.1~), systemd | systemd-tmpfiles, adduser, libudev1 (= 251.3-1)

Package: udev
Version: 251.2-7
Depends: libacl1 (>= 2.2.23), libblkid1 (>= 2.37.2), libc6 (>= 2.33), libcap2 (>= 1:2.10), libkmod2 (>= 5~), libselinux1 (>= 3.1~), adduser, libudev1 (= 251.2-7)


Yep. So much for the "systemd will never be mandatory in Debian"
promises. What a surprise! Debian's systemd zealots haven't even been
pretending they meant that for years now. It was discarded almost as soon as
they no longer needed it to get enough votes.

udev may not be flagged as "Essential: yes" but it is not an optional
package. Certainly not on a machine with X installed - xserver-xorg-core,
pulse-audio and about 100 other packages depend on it directly.


> > Aborting that and running 'apt upgrade' just highlights the cause:
> >
> > # apt -u upgrade
> > [...]
> >
> > The following packages have unmet dependencies:
> >  elogind : Conflicts: systemd
> >            Conflicts: systemd:i386
> >  libelogind0 : Conflicts: libsystemd0
> >                Conflicts: systemd
> >                Conflicts: systemd:i386
> > E: Broken packages
>
> AFAIK this should still work, but apt might need a bit of help to find the
> solution you want: it uses the first/default option which can lead it down the
> systemd route.

Nope, it doesn't. udev depends on systemd now.  There is no alternative.

> My suggestions:
>
>  - Ensure you have the correct apt sources and remove any pinning or held
>    packages.

My apt sources are fine - pointing at sid in my own local debian mirrors (i've
been mirroring debian since the 90s).

The only relevant held packages are sysvinit related.  If I unhold them, then
'apt dist-upgrade' just offers to remove them and install systemd instead.

>  - apt update

>  - Manually install the new elogind, libelogind and libpam-elogind.

Unless it was released today, there is no new debian package of elogind. or
related packages.  That's still 246.9.1-1+debian1 as it has been since Dec 23
2020.

I've been running apt update and then trying upgrade or dist-upgrade for the
last few days and getting the same result, hoping a new version of elogind
will be released.  And then I realised that's probably not going to happen
until someone files a bug report.


>  - apt upgrade
>
>  - apt dist-upgrade
>
> If you find apt is trying to install systemd at any of these steps, we need to
> identify the package that has a hard systemd dependency and deal with it.


> HTH. Let me know how you get on.

I'm going to make another attempt to switch this machine to systemd.  It's
been at least two years since I last tried.  Hopefully it will either work or
I'll be able to revert back to sysvinit (I've been able to do so in the past,
but it's always been a PITA chore).

Much as I loathe the way systemd steadily absorbs more and more stuff that has
nothing to do with init, it does make a decent init system as long as I can
disable all the unwanted bullshit.

This machine would have been switched to systemd years ago if systemd was
actually capable of booting it.  Having to maintain one machine that's
different from all my other machines is a PITA...a bigger PITA than the
constant vigilance against systemd's encroachments.

And, no, there's nothing unusual about this machine. It's an AMD FX 8150 on an
Asus Sabertooth 990FX motherboard.  I have another identical motherboard with
an AMD Phenom II 1090T which runs systemd without a problem.  And it's not the
FX 8150 CPU - this machine used to have an identical 1090T CPU, and systemd
wouldn't boot on it back then either.


craig

--
craig sanders <cas at taz.net.au>