Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

Sam Hartman hartmans at debian.org
Mon Sep 23 21:16:05 BST 2019

>>>>> "Mark" == Mark Hindley <mark at hindley.org.uk> writes:

    Mark> On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
    >> Foo-package depends on the latest libsystemd0.  I'm running
    >> unstable or testing.  The latest libsystemd0 isn't building on my
    >> arch yet.  But elogind is simpler and has build fine on my arch.
    >> I install foo-package and suddenly end up with libelogind0
    >> instead of libsystemd0
    >> This is probably a problem.  Libsystemd0 and libelogind0 probably
    >> behave differently and you probably do care which one you have.
    >> The specific problems depend on what init system I have, on
    >> whether I have elogind running or systemd-logind, etc.  But it's
    >> probably not a good situation.

    Mark> I believe we have guarded against exactly this already because
    Mark> libelogind0 conflicts with systemd, so you couldn't change
    Mark> from libsystemd0 to libelogind0 on a systemd install without
    Mark> removing the running systemd (which won't happen).

Well, we've guaranteed that you won't succeed.
With the apt fix, we've guaranteed  that the dependency order will be
respected for removal.

But I think it's still possible to get an incredible mess of your
There's no guarantee that systemd removal will happen early in the

    Mark> Anyway, I am happy to try to work up a dpkg-divert solution if
    Mark> that is likely to be more acceptable.

I don't know if it will be.
I'm trying to be a facilitator here and make sure all sides understand
each other.

So, the advantage of the dpkg-divert approach seems to me to be that if
you never turn it on, it can't hurt you.
So, for example, if you do more than install a package to trigger it, it
could be very safe for the systemd user.

Even if you trigger from the elogind postinst, that's probably OK so
long as very little hard depends on elogind.

The disadvantages are:

1) Making sure you never get into a situation where you try to boot
systemd with libelogind0.  Assuming you can dpkg-divert a symlink, you
can presumably manage the /sbin/init link, but you cannot stop someone
from init=/bin/systemd with libelogind0 as libsystemd0.  Although
systemd doesn't actually link to libsystemd0, so perhaps that's not
quite as bad as I thought, although I'm sure it isn't good..  (You may
not need to stop this: it's a disadvantage, and sometimes the chosen
solution has disadvantages).

2) There was FUD about dpkg-divert being inappropriate for critical
system functions.  I don't know whether this is still true or how big of
a deal it is.  But for example if things are in an inconsistent state on
upgrade between unpack phase and configure phase, that might be a
disadvantage.  Basically, I think it's probably fine if the initial
diversion has some fragility (where if your system crashes at that one
point, recovery is hard).  I think it's less amazing if every time you
upgrade systemd, elogind or similar, there is fragility.

Really at this point we need someone who is not you or I to speak up.

More information about the Debian-init-diversity mailing list