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