El mar, 21 de oct 2014 a las 10:19 , Tollef Fog Heen <tfheen@err.no> escribió:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">]] Russ Allbery
Hello Russ, CTTE,
<blockquote> 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.
</blockquote>
The currently implemented approach is largely the same as what we
proposed and discussed publicly back in July
(<a href="https://lists.debian.org/debian-devel/2014/07/msg00611.html">https://lists.debian.org/debian-devel/2014/07/msg00611.html</a>). 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 (<a href="https://bugs.debian.org/757298">https://bugs.debian.org/757298</a>), 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.
<blockquote> 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.
</blockquote>
In a steady state, this would probably be ok. However, we've so far seen
two instances of -shim breaking for systemd users
(<a href="https://bugs.debian.org/746242">https://bugs.debian.org/746242</a> and <a href="https://bugs.debian.org/765101">https://bugs.debian.org/765101</a>), by
shipping outdated security policies. We are worried that this will
happen again on future updates of systemd.</div></blockquote><div><br></div><div>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? <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765101#38">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765101#38</a></div><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">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.</div></blockquote><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">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.
<div>--
</div>Tollef Fog Heen, on behalf of the systemd team
UNIX is user friendly, it's just picky about who its friends are</div></blockquote><br><div>Thanks,</div><div>--</div><div>Cameron Norman</div>