Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Cameron Norman]

El mar, 21 de oct 2014 a las 10:19 , Tollef Fog Heen <tfheen at err.no> 
escribió:
> ]] Russ Allbery
> 
> Hello Russ, CTTE,
> 
>>  Hello, systemd maintainers.
>> 
>>  We (the Technical Committee) have received a request to override a
>>  maintainer decision around whether systems are switched from 
>> sysvinit to
>>  systemd on upgrade.  However, it's not clear to me that an actual 
>> decision
>>  has been made that we would need to override.
>> 
>>  There have been multiple (fairly high-noise) discussions in 
>> debian-devel
>>  about this, and some previous concrete design discussion, but in 
>> all of
>>  the other, mostly unproductive threads on this topic, I've lost 
>> track of
>>  status or the current proposed approach.
> 
> The currently implemented approach is largely the same as what we
> proposed and discussed publicly back in July
> (https://lists.debian.org/debian-devel/2014/07/msg00611.html). It's
> based on work by Steve Langasek, who did the groundwork to do the 
> switch
> on upgrades within one release cycle by splitting up the sysvinit
> package and moving the contents into a new, non-essential 
> sysvinit-core
> package.
> 
> A summary of the changes:
> 
> 1/ Introduction of a new, essential meta package named "init", which
>    depends on systemd-sysv | sysvinit-core | upstart
> 
> 2/ sysvinit became a transitional package, which is non-essential, and
>    pre-depends on "init".
> 
> 3/ Adjusting priorities of affected packages accordingly.
> 
> New installations
> =================
> The new "init" package will ensure that systemd-sysv is installed as
> default init on Linux and by demoting the priority of sysvinit and
> sysvinit-core to optional those packages will not be installed 
> anymore.
> 
> Upgrades
> ========
> On upgrades, the old, essential sysvinit package will be replaced by 
> the
> new, non-essential sysvinit package which pulls in the new "init"
> package which in turn makes sure systemd-sysv is installed.
> 
> In summary, on both new installations and upgrades, the default is
> switched.
> 
> Upgrade safety measures
> =======================
> An important detail is, that on upgrades, we keep the sysvinit package
> installed, which ships /lib/sysvinit/init. This makes it very easy to
> boot using sysvinit, even if systemd is the default /sbin/init. We
> proposed a patch for grub2 (https://bugs.debian.org/757298), which 
> makes
> this even more straightforward. Unfortunately this patch hasn't been
> merged yet and we are still waiting for a reply from the maintainer.
> 
> One change is that we see there is a need for a check in postinst that
> will look for common misconfigurations and potential errors and if so,
> inform the user about those problems and how he can fix those or roll
> back to sysvinit (which is basically as simple as running apt-get
> install sysvinit-core). We'd like to ship those checks in a dedicated
> script, which can be run by the user at any time.
> 
> So far, we believe that the best course of action is, to only show 
> that
> debconf prompt if potential problems are detected. This could be 
> easily
> changed though, to always show the debconf prompt on upgrades to raise
> awareness and visibility of the change.
> 
> We believe it is a bad idea to stop changing to systemd on upgrades. 
> One
> of the reasons for this is we have the dependencies in place to 
> actually
> get upgrades and initial installations to behave as specified. If we
> change how we want this done, somebody needs to sit down and do that
> work again, testing all the various edge cases. Getting this right is
> not trivial. Two weeks before the freeze is pretty late to start that
> work.
> 
> Prior art
> =========
> We also like to mention, that there is prior art regarding this
> change. When we switched to dependency based booting in squeeze, this
> was done on new installations as well as on upgrades.
> 
>>  I would be particularly interested in your take on the analysis 
>> that Steve
>>  Langasek posted to the debian-devel thread on why listing 
>> systemd-shim as
>>  the first alternative dependency for libpam-systemd makes sense and 
>> should
>>  not cause any negative effects for systemd users.
> 
> In a steady state, this would probably be ok. However, we've so far 
> seen
> two instances of -shim breaking for systemd users
> (https://bugs.debian.org/746242 and https://bugs.debian.org/765101), 
> by
> shipping outdated security policies. We are worried that this will
> happen again on future updates of systemd.

Josh Triplett proposed a long term solution to the problem you point 
out here that will work across systemd upgrades. What are your thoughts 
on that solution? 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765101#38
> We are also worried about it still having release critical bugs and 
> the
> feedback we are hearing from the desktop maintainers is that they see
> bugs which are tracked down to bugs in -shim. We therefore don't 
> believe
> that is a good choice for desktop users.

> Steve's argument is that choosing sysvinit-core over systemd-sysv 
> should
> automatically reflect on choosing systemd-shim over systemd-sysv. We 
> do
> not necessarily think this is the case and both decisions need to be
> taken on their own.
> 
> --
> Tollef Fog Heen, on behalf of the systemd team
> UNIX is user friendly, it's just picky about who its friends are

Thanks,
--
Cameron Norman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20141021/e68d8345/attachment-0002.html>