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

[Mark Hindley]

On Mon, Sep 23, 2019 at 04:16:05PM -0400, Sam Hartman wrote:
>     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.

I have got a PoC dpkg-divert solution working.  The divert created in
elogind.postinst and removed in elogind.prerm. The libsystemd.so compatibility
symlink is also handled there. It works as far as it goes and it means that
libelogind0 can be coninstalled with libsystemd0. However, it is fragile because
the file that needs to be diverted out of the way is libsystemd.so.0.26.0 (the
actual library file, not a symlink) otherwise ldconfig will still find it and
create symlinks. However, AFAICS dpkg-divert doesn't accept wildcards and so if
the minor soversion is bumped and a new version of libsystemd0 is installed, the
new file is installed without a divert and ldconfig redirects the symlink.

I can't work out a way around this at the moment, but any suggestions are
welcome.

Thanks

Mark