Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

Mark Hindley mark at hindley.org.uk
Tue Aug 13 19:58:09 BST 2019


Thorsten,

Thanks for this.

On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote:
> On Sun, 11 Aug 2019, Simon McVittie wrote:
> 
> > Found while preparing a test VM to test #923240. Please raise this to
> > RC severity if you think it is justified - I don't want to create the
> 
> I don’t think it’s RC in any of the involved packages (elogind,
> systemd (shock!), apt) because it’s really a whole-system / package
> management issue.

Yes, that is my conclusion after 2 days of trying different things. Certainly
systemd's prerm failure is pretty brutal. But this happens before any of the
src:elogind preinsts run, so I can't see a way around it. If anything, it is a
limitation in apt (although I am not trying to pass the buck here).

> > Actual result (transcript below):
> > 
> > * systemd-sysv is removed
> > * sysvinit-core is unpacked
> > * systemd is also removed
> > * systemd's prerm fails because it is still the active init system
> 
> Interesting. But this probably happens before the preinst of
> libelogind0 and does prevent its installation, which is not
> something easily circumvented.

systemd depends on a specific pacakged version of libsystemd0 (currently 241-7
in sid) whilst all other packages at most depend on a particular src version
(eg. >= 213). libelogind Provides libsystemd0 (= ${source:Upstream-Version}) so
the attempted removal of systemd is not triggered  by any Conflict with
libelogind, but by the removal of libsystemd0 *before* replacing it with
libelogind0.

So far, I haven't discovered a way to mitigate or preempt that.

I would also add that it surprises me that apt requires symbols from
libsystemd.so. I haven't yet investigated what functionality that is. But that
is a side issue.

Mark




More information about the Debian-init-diversity mailing list