Bug#762194: Automatic switch to systemd on wheezy->jessie upgrades (thoughts)
Dear ctte,
after having watched this discussion from the sidelines a bit, I'd
like to offer a few thoughts on this topic.
First of all, as for the technical issue of how to NOT cause the init
system to be switched when updating from wheezy to jessie: all
proposed solution I've seen in this thread don't appear to be helpful:
- Switchig depends order of init [1]
(sysvinit-core before systemd-sysv)
-> won't work, because init is Essential, but systemd-sysv isn't,
so this change would default the init system to sysvinit for
jessie (which is against the TC ruling from earlier this year,
so unless you'd want to overrule that... ;-))
- Adding sysvinit to dependencies of init [2]
(Depends: systemd-sysv | sysvinit | sysvinit-core | upstart)
-> won't work, becaues the sysvinit package in Jessie is just
transitional (co-installable with any init system) and
contains two files: /lib/sysvinit/init and
/lib/sysvinit/telinit
-> this means that /sbin/init wouldn't be provided anymore
(systems won't boot)
-> also, this is a dependency loop (sysvinit Pre-Depends on
init in jessie, to make sure the init metapackage is always
installed on updates) Don't know what the effect of that
would be
-> of course, one could add
Depends: sysvinit-core | systemd-sysv | upstart
to sysvinit in Jessie, but with the experience I've had testing
dependency resolvers recently, I wouldn't trust that all
dependency resolvers will be able to properly process this,
especially for people that are already running jessie now with
the current set of dependencies
- Obviously, if this had been discussed earlier, a different package
structure could have been chosen in the first place, but that ship
has sailed...
- (Have I missed something?)
Therefore, for the sake of discussion, I'd like to show a different
mechanism by which the switch could be avoided. Note that I do not
propose that you actually do this (I'm unsure about the correct
decision on this topic, see below), I only want to show that there is
indeed a sane possibility to achieve this.
The main advice for user's upgrading that want to keep sysvinit is
currently to install the sysvinit-core package before actually
upgrading the rest of the system. Therefore, this behavior could be
leveraged by introducing a trivial empty package 'sysvinit-core' to
wheezy and make 'sysvinit' in wheezy depend on it.
I've tried this with the following patch to wheezy's (!) sysvinit
package:
======================================================================
--- old/debian/control 2013-07-14 19:19:01.000000000+0200
+++ new/debian/control 2014-12-04 15:14:16.569409781+0100
@@ -26,7 +26,9 @@
# For ischroot
debianutils (>= 4),
# Required for TERM=xterm switch (see #605777)
- kbdcontrol (>= 8.2+ds2-6) [kfreebsd-any]
+ kbdcontrol (>= 8.2+ds2-6) [kfreebsd-any],
+# For jessie upgrades
+ sysvinit-core
Description: System-V-like init utilities
This package contains programs required for booting
a Debian system and doing basic process management.
@@ -50,6 +52,15 @@
Specifically, this package includes:
killall5, last, lastb, mesg, pidof, service, sulogin
+Package: sysvinit-core
+Architecture: any
+Description: System-V-like init utilities
+ This package is a transitional package to facilitate transitions to
+ Debian 8 (jessie).
+ .
+ The consequence of this package is that updates to the next Debian
+ version will not change the init system.
+
Package: sysv-rc
Architecture: all
Recommends: lsb-base (>= 3.2-14)
======================================================================
This has the following consequences:
- wheezy systems running sysvinit will not switch init systems on
upgrade (tested with apt-get and aptitude on the command line),
i.e. keep sysvinit as init system
- wheezy systems running systemd-sysv (forced removal of sysvinit
essential package) will also keep their current init system, in
this case systemd
- jessie systems are unaffected, because this change is in wheezy
Therefore, if you really want to prevent init system changes from
wheezy to jessie, given the current state of affairs, this appears to
be the sanest solution, at least from a technical standpoint.
Obviously, this is someting that should probably be discussed with
the release team first, if you really intend to go that route. And
obviously, you should keep in mind that this will then only work for
people who keep their wheezy systems up-to-date.
[1] https://lists.debian.org/<20141122132116.GB14518@angband.pl>
[2]
https://lists.debian.org/<CALZWFRJ_Qv1vPWRCvTR7hAkJ1ivw8nn_dMZP8H1Q8XkBBZk-AA@mail.gmail.com>
----------------------------------------------------------------------
Second part of this email: Having said that, a few thoughts on the
question of switching init systems:
Arguments FOR switching on upgrade:
+ it shouldn't matter whether you upgrade your system or freshly
install it, so the init system should be the same unless the
user explicitly wants another (which they can do in either
case)
+ related to the first point: user support: support for Debian
users might be more difficult otherwise, especially for people
who don't care about their init system and don't realize that
the fact that they upgraded made their installation different
from a freshly installed one
+ systemd is considered better by the Debian project (in the
sense that it has been decided to be default and nobody
challenged that) - and users should get that, regardless of
their path to jessie, unless they specifically object to it
- counter to that: as we see with the backlash, some people
consider systemd to be a really, really bad idea, and not
at all better than sysvinit
Arguments AGAINST switching on upgrade:
- principle of least surprise: some people may not expect their
system to work differently after an upgrade
+ counter to that: other core parts of the system have also
been replaced in the past (devfs -> udev, etc.)
- counter to that: those had less of an impact on the
administrator than systemd
+ counter to that: udev, really? also: ELF,
libc6, ...
+ there are release notes for people who care, and ways to
avoid that
- upgrade safety: some local setups may rely on sysvinit behavior
implicitly, for example:
* /etc/inittab modifications (not considered by systemd)
* custom /etc/init.d scripts that don't properly with
systemd (for example, due to wrong exit codes)
* /etc/fstab vs. nofail vs. emergency shell
+ counter to that: there are people working on detecting
these issues and providing information in postinst scripts
for this issue
+ counter to that: past upgrades have always had some kind
of breaking of local configurations, even if it was just
a new software version
- other Debian defaults have also not been switched (MTA, syslog,
etc.)
Another bit of food for thought:
Let's say for jessie+2 the situation is reverse: systemd is the
default, but the new default is supposed to be awesomeinitd, (yet to
be written ;-)) because that turned out to be much better than
systemd. Would you want to the default init system to switch then?
- if you think the default init should not be switched then, why
is wheezy->jessie different?
- is it because wheezy didn't really have a choice what
your init system was going to be (without removing
essential packages at least, and TBH, systemd in wheezy
was not quite ready for production yet)? But why should
that matter?
- or you don't think it's different, and then you would
want to keep sysvinit for wheezy->jessie
- if you think the default init should be switched then, I think
the current dependencies of the 'init' package in jessie are
wrong. Because then any upgrade from jessie to a later version
with a changed dependency order of the 'init' metapackage will
NOT cause another init system to be installed (unless the one
you've been using in jessie has been removed), but will in fact
ensure that the current init will be kept
- so if in fact you'd want to switch init systems by default on
the next upgrade, the proper dependencies for the 'init'
metapackage should probably be something like
Depends: default-init | systemd-sysv | sysvinit-core | upstart
And 'default-init' should depend on just 'systemd-sysv'.
=> Then, for the next time the init system changes,
'default-init' could just be changed to the new init
system, and people who'd want to keep systemd anyway would
just remove the 'default-init' package.
(Note this is completely untested, just thinking out loud, so
maybe this won't work anyway.)
- or you'd have to have the new Debian release have a completely
new set of packages that replace the current ones that kind
of make this work anyway (which is probably not impossible,
but probably also quite difficult to figure out)
Finally, on a more social level, I haven't seen many Debian members
that would be directly affected by such a decision participating in
this discussion, so it might be a good idea to reach out to the
relevant people before deciding that issue.
Christian
Reply to: