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-de...@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?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers