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

[Mark Hindley]

On Wed, Sep 25, 2019 at 10:09:15PM +0200, Thorsten Glaser wrote:
> On Wed, 25 Sep 2019, Mark Hindley wrote:
> 
> > 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.
> 
> Yes, this is not a good idea.
> 
> You could do with a trigger on /usr/lib/ and a wildcard-expanding
> shell loop in postinst, which is also a tad fragile.

Thanks. Triggers may be an answer to the libsystemd soversion issue.

> dpkg-divert also has a small period in which neither is available.
> I don’t like this approach.

In this usage case, I believe I have avoided this being a problem. The flow to
switch to libelogind.so goes

 1) symlink libelogind.so.0 to a temporary file.
 2) rename temporary file to libsystemd.so.0 (I believe this is atomic).
 3) dpkg-divert libsystemd.so.0.26.0 out of the way so ldconfig can't find it.
 4) Whenever ldconfig runs the manual symlink libsystemd.so.0 -> libelogind.so.0
    is preserved.

I believe using a temporary file and then renaming means there is no point at
which there is a valid libsystemd.so.0 symlink. But I could be wrong.

This isn't the same as the 'standard' dpkg-divert when a file is moved out of
the way so another can be installed in it's place

Is this still flawed?

Thanks

Mark