El mar, 21 de oct 2014 a las 10:19 , Tollef Fog Heen <tfh...@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