Bug#748355: Upgrading from sysvinit/wheezy to systemd-sysv/sid impossible due to loop
On Fri, May 16, 2014 at 06:53:27PM +0200, Sven Joachim wrote: On 2014-05-16 17:33 +0200, Michael Biebl wrote: Incidentally we also discussed dropping the Conflicts from systemd-sysv and only keeping the Replaces (and this is also what sysvinit-core has done). Which has its own problems, since nothing stops the admin from shooting themselves in the foot by installing sysvinit-core without upgrading sysvinit and then removing sysvinit-core. Stopping admins from shooting themselves in the foot by running a stupid sequence of apt commands without understanding what they're doing, should not be given higher precedence than ensuring that the vast majority of our users are able to cleanly upgrade by following our standard upgrade instructions. So yes, it's a downside that this is possible when using the Replaces without Breaks or Conflicts, but it's definitely a lesser evil. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#748355: Upgrading from sysvinit/wheezy to systemd-sysv/sid impossible due to loop
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. 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 … signature.asc Description: Digital signature
Bug#748355: Upgrading from sysvinit/wheezy to systemd-sysv/sid impossible due to loop
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
Bug#748355: Upgrading from sysvinit/wheezy to systemd-sysv/sid impossible due to loop
On 2014-05-16 17:33 +0200, Michael Biebl wrote: Incidentally we also discussed dropping the Conflicts from systemd-sysv and only keeping the Replaces (and this is also what sysvinit-core has done). Which has its own problems, since nothing stops the admin from shooting themselves in the foot by installing sysvinit-core without upgrading sysvinit and then removing sysvinit-core. 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. This switch makes it totally unpredictable whether you end up with systemd-sysv or sysvinit-core + systemd-shim, indeed. Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
