]] Russ Allbery Hello Russ, CTTE,
> Hello, systemd maintainers. > > We (the Technical Committee) have received a request to override a > maintainer decision around whether systems are switched from sysvinit to > systemd on upgrade. However, it's not clear to me that an actual decision > has been made that we would need to override. > > There have been multiple (fairly high-noise) discussions in debian-devel > about this, and some previous concrete design discussion, but in all of > the other, mostly unproductive threads on this topic, I've lost track of > status or the current proposed approach. The currently implemented approach is largely the same as what we proposed and discussed publicly back in July (https://lists.debian.org/debian-devel/2014/07/msg00611.html). It's based on work by Steve Langasek, who did the groundwork to do the switch on upgrades within one release cycle by splitting up the sysvinit package and moving the contents into a new, non-essential sysvinit-core package. A summary of the changes: 1/ Introduction of a new, essential meta package named "init", which depends on systemd-sysv | sysvinit-core | upstart 2/ sysvinit became a transitional package, which is non-essential, and pre-depends on "init". 3/ Adjusting priorities of affected packages accordingly. New installations ================= The new "init" package will ensure that systemd-sysv is installed as default init on Linux and by demoting the priority of sysvinit and sysvinit-core to optional those packages will not be installed anymore. Upgrades ======== On upgrades, the old, essential sysvinit package will be replaced by the new, non-essential sysvinit package which pulls in the new "init" package which in turn makes sure systemd-sysv is installed. In summary, on both new installations and upgrades, the default is switched. Upgrade safety measures ======================= An important detail is, that on upgrades, we keep the sysvinit package installed, which ships /lib/sysvinit/init. This makes it very easy to boot using sysvinit, even if systemd is the default /sbin/init. We proposed a patch for grub2 (https://bugs.debian.org/757298), which makes this even more straightforward. Unfortunately this patch hasn't been merged yet and we are still waiting for a reply from the maintainer. One change is that we see there is a need for a check in postinst that will look for common misconfigurations and potential errors and if so, inform the user about those problems and how he can fix those or roll back to sysvinit (which is basically as simple as running apt-get install sysvinit-core). We'd like to ship those checks in a dedicated script, which can be run by the user at any time. So far, we believe that the best course of action is, to only show that debconf prompt if potential problems are detected. This could be easily changed though, to always show the debconf prompt on upgrades to raise awareness and visibility of the change. We believe it is a bad idea to stop changing to systemd on upgrades. One of the reasons for this is we have the dependencies in place to actually get upgrades and initial installations to behave as specified. If we change how we want this done, somebody needs to sit down and do that work again, testing all the various edge cases. Getting this right is not trivial. Two weeks before the freeze is pretty late to start that work. Prior art ========= We also like to mention, that there is prior art regarding this change. When we switched to dependency based booting in squeeze, this was done on new installations as well as on upgrades. > I would be particularly interested in your take on the analysis that Steve > Langasek posted to the debian-devel thread on why listing systemd-shim as > the first alternative dependency for libpam-systemd makes sense and should > not cause any negative effects for systemd users. In a steady state, this would probably be ok. However, we've so far seen two instances of -shim breaking for systemd users (https://bugs.debian.org/746242 and https://bugs.debian.org/765101), by shipping outdated security policies. We are worried that this will happen again on future updates of systemd. We are also worried about it still having release critical bugs and the feedback we are hearing from the desktop maintainers is that they see bugs which are tracked down to bugs in -shim. We therefore don't believe that is a good choice for desktop users. Steve's argument is that choosing sysvinit-core over systemd-sysv should automatically reflect on choosing systemd-shim over systemd-sysv. We do not necessarily think this is the case and both decisions need to be taken on their own. -- Tollef Fog Heen, on behalf of the systemd team UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org