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

[Mark Hindley]

Sam,

Since I cannot get a working and robust dpkg-divert solution, I feel the need to
revisit the validity of these concerns.

On Mon, Sep 23, 2019 at 03:03:57PM -0400, Sam Hartman wrote:
> >>>>> "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.

Yes, it would be a problem if that was what happened, but if this system had
systemd installed, the current dependencies do not allow it. If systemd wasn't
installed it might happen. However, I don't think that would cause any change in
function. There appears to be some mystique as to what libsystemd0 and
libelogind0 do. Their only function is to provide library API access to a
running systemd or elogind process. In the absence of that, they do nothing
beyond satisfying the runtime linker.

> 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.

Yes, so problems and loss of functionality are caused only if you end up with
the combination systemd/libelogind0 or elogind/libsystemd0. Current dependencies
make the first of these impossible and second one is what we are trying to
provide a solution to.

To be sure, I have just tried to install libelogind0 on a sid VM booted with
systemd. APT will not let you do it requiring you to type the 'Yes, do as I
say!' phrase after its serious warning which is surely enough to dissuade most
people from proceeding. The dependency stack is

 init (Priority: important) PreDepends systemd-sysv
  systemd-sysv (Priority: important) PreDepends systemd
   libelogind0 conflicts systemd

Given that, I can see no way libelogind0 could accidentally be installed on a
system with systemd.

It is possible to get APT to attempt a solution by specifically requesting 'apt
install libelogind0 sysvinit-core'.  This removes systemd-sysv and then fails
gracefully when the systemd prerm fails. 'apt -f install' successfully cleans up
by configuring sysvinit-core. This would only be specified by a user wanting to
switch to an non-default init and is not going to happen by accident.
Importantly in this scenario, libelogind0 is still not installed and the system
including systemd as init still functions. If you realise you have made a
mistake you can even return to systemd-sysv just by reinstalling it.

I hope you don't feel I am going over old ground here, but I fail to see a case
that is not covered. What am I missing?

Mark