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

Bug#762194: Automatic switch to systemd on wheezy->jessie upgrades



Package: tech-ctte

At the risk of generating confusion due to a duplication of threads:

It appears that the answer to #746578 (libpam-systemd dependency) does
not depend on whether users upgrading should be switched to systemd by
default.  The current state in jessie is that users are switched by
default.  This is controversial.  The Technical Committee should make
a decision about this.

My view is that users should not be automatically switched when
upgrading to jessie.  As I said in my intro to #746578:

This is especially important given the controversy, and our commitment
to support multiple init systems.

This would also be analogous with other similar decisions.  For
example, if the default desktop for jessie remains XFCE, we do not
expect users upgrading from wheezy to have GNOME replaced with XFCE.
If we were to change the default MTA or nameserver or syslogd, we
would not expect to replace the installed MTA or nameserver or syslogd
on existing systems.

There are also of course important practical problems with
automatically switching.  There have been suggestions that these
should be dealt with by automatically detecting problem cases.  But we
do not yet have a coherent design for such an approach, let alone an
implementation.  It is IMO too late in the jessie release cycle for us
to be developing and introducing such a thing.  This is particularly
true given that the details are likely to be contested.

I think that the TC's correct approach is probably to make a bare
statement that:

    Users upgrading to jessie should, by default, not be automatically
    switched from sysvinit to systemd.

    A straightforward mechanism for making the switch should be
    provided and documented.

The alternative would be:

    Users upgrading to jessie should, by default, be automatically
    switched from sysvinit to systemd, where feasible.

    A straightforward mechanism for avoiding the switch should be
    provided and documented.

The detailed implications of what this means for dependencies should
be dealt with separately if the implementation runs into trouble or
conflict.

Ian.


Reply to: