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

Re: How to avoid stealth installation of systemd?

On Tue, Jul 01, 2014 at 06:09:08PM +0200, Marco d'Itri wrote:
> On Jul 01, Carlos Alberto Lopez Perez <clopez@igalia.com> wrote:

> > I think that a critical debconf warning should be in place to avoid
> > replacing the init system of users without prior explicit consent.
> I think that this would be an annoying waste of time for most users, 
> since only a few people care so much about not being tainted by systemd.

I agree with you (and disagree with Russ) that we shouldn't give everyone a
debconf prompt on upgrade.

But you are willfully misrepresenting the problem.  People care that *their
system doesn't break*; users do not currently have confidence that upgrading
to systemd won't break their system, and this thread started because of a
bug that happened after upgrade.  Finding such bugs, and seeing them closed
with no action, does nothing to inspire further confidence that systemd is
going to be a smooth upgrade.

Whenever anyone expresses concern about systemd reliability on Debian,
systemd apologists are quick to say that it works on their system.  This is
worth exactly nothing.  A wet ball of string would boot 80% of system
configurations; the question is, are we going to live up to Debian's good
name and support the other 20%, or are we going to make every one of those
other users fend for themselves?

There needs to be a lot less sneering at users who are unhappy with systemd,
and a lot more taking ownership of the real and actual issues users are
running into on upgrade.

In this particular case, the problem is a tough one to solve.  systemd is
pulled in by default on upgrade, which we want; but logind won't work unless
there's a process running that provides the systemd dbus interface.  There
are two possible implementations of this interface: systemd-shim, which at
present is only compatible with systemd-logind up to 204; and systemd
itself, which obviously requires a reboot to take effect.

I think the current default to pull in systemd-sysv and not systemd-shim is
wrong, because of the problems introduced on upgrade before rebooting to the
new init.  But the systemd maintainers are anxious to update to a newer
version in unstable, and while there are plans in Ubuntu to make
systemd-shim support the interfaces needed for newer logind, this isn't
ready yet.  If we take systemd 208 into jessie, and systemd-shim
compatibility doesn't land, this means an unavoidably bad experience for
users pre-reboot on upgrade:  the power button won't work (as shown), a
desktop user will not be able to sanely re-login post logout (again due to
logind), various things like brightness controls are AIUI likely to stop

To deliver a proper upgrade experience in jessie, I believe the right answer

 - hold systemd back at 204 until systemd-shim is updated
 - switch the dependency from libpam-systemd to pull in systemd-shim, not
   just systemd-sysv
 - update sysvinit to pull in systemd-sysv by default
 - once systemd-shim supports the 208 interfaces, update systemd
 - post-jessie, drop the dependency on systemd-shim to a non-default

This would ensure that users' systems continue to work correctly on upgrade,
rather than being left broken after reboot.  At the same time, it should
ensure that users who upgrade to jessie will by default get systemd as init
on the first reboot, which is what we want.

I don't believe there is a good argument for why we should take a newer
upstream version of systemd for jessie if it means subjecting our users to
pre-reboot breakage on upgrades.

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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: