[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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

     + 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,

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.


Reply to: