On Tue, Jul 01, 2014 at 06:09:08PM +0200, Marco d'Itri wrote: > On Jul 01, Carlos Alberto Lopez Perez <clo...@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 working. To deliver a proper upgrade experience in jessie, I believe the right answer is: - 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 alternative 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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
