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

[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.


Best regards

David Kalnischkies

P.S.: Full-disclosure bla bla: At the moment a third solution would be
for apt to temporary install sysvinit-core, to be able to install the
new version of sysvinit, so that it in turn can remove sysvinit-core
again and replace it with systemd-sysv. Yes, that would be insane and
is not even close to be supportable as a scenario by apt …
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20140516/d81be469/attachment.sig>