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

[Sam Hartman]

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


    >> If we are going to use c/r/p libsystemd0, is there some way we
    >> can limit the potential damage to people who have positively
    >> indicated that they want to run a non-default init system?  One
    >> of the concerns is what happens if apt decides somehow that it
    >> wants to install libelogind0 when you don't expect it.

    Mark> I have to admit I don't understand this fear. libsystemd0 is
    Mark> just a way of talking to a running systemd process. If systemd
    Mark> is not running and PID 1 libsystemd0 APIs generally return non
    Mark> fatal errors. So by running a non-default init, libsystemd0 is
    Mark> only there to satisfy dynamically loaded symbols at
    Mark> runtime. Otherwise it is basically non functional. libelogind0
    Mark> is the same if elogind isn't running.

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.


The concern is there might be other cases where the dependency resolver
gives you an answer that is inappropriate for your environment.  We're
not sure we have confidence we can enumerate and think about all these
situations.


This is less likely with things like mail-transport-agent because the
dependencies are closer to their usage, or because the size of the
interacting parts of the dependency graph are smaller.