Bug#748355: Upgrading from sysvinit/wheezy to systemd-sysv/sid impossible due to loop

[Michael Biebl]

Am 16.05.2014 16:26, schrieb David Kalnischkies:
> Package: systemd-sysv
> Version: 204-10
> Severity: serious
> Justification: triggers a debian-policy defined dpkg error (§7.4)
> X-Debbugs-CC: pkg-sysvinit-devel at lists.alioth.debian.org
> 
> Hi *,
> 
> I got a report (now…) that apt segfaults in a wheezy → sid upgrade.
> Debugging this leads to the following universe (hugely simplified):
> 
> Package: sysvinit
> Version: 1
> Essential: yes
> 
> Package: sysvinit
> Version: 2
> Pre-Depends: sysvinit-core | systemd-sysv
> Essential: yes
> 
> Package: sysvinit-core
> Version: 2
> 
> Package: systemd-sysv
> Version: 2
> Conflicts: sysvinit (<< 2)
> Breaks: sysvinit-core
> 
> 
> If we have sysvinit v1 installed and want to install systemd-sysv now
> we not only run into the previously mentioned segfault, but, if the
> segfault would not appear and dpkg actually executed we get:
> | Selecting previously unselected package systemd-sysv.
> | dpkg: considering deconfiguration of sysvinit, which would be broken by installation of systemd-sysv ...
> | dpkg: no, sysvinit is essential, will not deconfigure
> |  it in order to enable installation of systemd-sysv
> | dpkg: error processing archive /tmp/tmp.W9nkJhRQvg/aptarchive/pool/systemd-sysv_2_amd64.deb (--unpack):
> |  installing systemd-sysv would break existing software
> | Errors were encountered while processing:
> |  /tmp/tmp.W9nkJhRQvg/aptarchive/pool/systemd-sysv_2_amd64.deb
> | E: Sub-process fakeroot returned an error code (1)
> 
> The reason is "simple":
> Unpacking systemd-sysv is not possible before we have gotten right of
> sysvinit 1. The normal solution is to just upgrade it to version 2, but
> this requires us to first unpack systemd-sysv -> loop.
> The other solution is to temporary remove sysvinit 1 and reinstall it
> later on. Such a practice isn't allowed for essential packages.
> Debian policy §7.4 even explicitly defines that dpkg should error out if
> it is attempt, which is what you get at the moment (minus a segfault).
> Note that Breaks will not work either (same message).
> 
> 
> I see two probably good-enough solutions:
> 1. Downgrade Pre-Depends in sysvinit to a Depends
> Technical it isn't entirely correct as it would be allowed to have
> an unpacked sysvinit then, but not a working init system. In theory I
> assume this window of opportunity to be very small as APT treats Depends
> of a (pseudo-)essential package if at all possible as Pre-Depends and
> also tries to configure them as soon as possible. In practice it should
> mean that they are unpacked in the same dpkg call, so if you can write
> your maintainerscripts without requiring runlevel, shutdown and co this
> should work out.
> 2. Remove Conflicts: sysvinit (<< 2) from systemd-sysv
> It is only for the file replacement, right? (In which case Breaks would
> have equally (not) worked). dpkg is happy as long as it has Replaces, so
> we talk mostly about partial upgrades and downgrades here and while I
> tried to come up with a good scenario in which something would break,
> I failed to find one given that both seem to work with the binaries of
> the other at least somehow.
> (This 2nd solution is btw deployed in sysvinit-core, so just in case
>  someone requests adding a Conflicts/Breaks here: be careful)
> 
> 
> I guess 'solution' 2 is preferable, so I report against systemd, but
> have CC'ed sysvinit maintainers. Feel free to disagree and reassign
> and/or invent another (better) solution.

Thanks David for the bug report.
We stumbled upon this issue already and discussed it within the
pkg-systemd team and with Steve.
IIRC Steve considered this to be a bug in apt, that it failed to compute
a proper upgrade path. I vaguely remember that I wanted to file a bug
report against apt for that, but apparently I missed that. So thanks for
raising this issue.

Incidentally we also discussed dropping the Conflicts from systemd-sysv
and only keeping the Replaces (and this is also what sysvinit-core has
done).

I'm a bit surprised though, that a user has hit this issue, since
sysvinit still has sysvinit-core as first alternative. This might be due
to the switch in libpam-systemd though.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140516/41bef9ea/attachment-0002.sig>