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

Bug#746578: Reasons to keep systemd-sysv as the first alternative

On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote:
> On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery <rra@debian.org> wrote:
> > I conceptually dislike the user experience of switching init systems
> > because the user upgraded some random package that, from their
> > perspective, doesn't appear related to the init system.  I feel like
> > switching init systems should be a more intentional action than that.
> > There is a variety of local customization that is init-system-specific,
> > and I'm dubious that we're going to be able to catch and warn about all of
> > it.

> > I've not made up my mind about the merits of switching init systems from
> > sysvinit to systemd during a dist-upgrade, but if we do that, I think we
> > should do it via some more deliberate and obvious method than pulling
> > systemd-sysv in via the dependency tree of some random package.  The
> > partial upgrade UX for that is really bad, IMO.

> I agree completely that it doesn't make sense for the transition from
> sysvinit to systemd to take place via libpam-systemd rather than via
> some core package like "init",

And yet you are arguing that the libpam-systemd dependency should not be
inverted, for political (not technical) reasons.

If the systemd-shim package is currently broken and should not be allowed to
satisfy the libpam-systemd dependency, then that should be expressed as a
release-critical bug keeping it out of the release, *not* by the systemd
maintainers placing conditions on the ordering of the alternative
dependencies.  The correct way to avoid libpam-systemd triggering a switch
of init system is for libpam-systemd to list the conservative alternative
first in the dependency list.

If we decide that init should not be automatically changed on upgrade[1],
then it should not be automatically changed on upgrade for /any/ users,
including those who have desktop software installed.  The way to accomplish
this is to list systemd-shim as the first alternative dep.

If we decide that init *should* be automatically changed on upgrade, then
the ordering of the dependencies on libpam-systemd is immaterial except in
the specific case that someone has upgraded to (or newly installed) jessie,
selected an init system other than the default, and subsequently installed a
desktop environment on a system that didn't initially have one.  In this
case, installing the DE *definitely* should not override the user's
explicit selection of init system.

In both cases, the way to achieve the desired result is for libpam-systemd
to depend on systemd-shim | systemd-sysv, *not* on systemd-sysv |

If the bugs in systemd-shim are too severe to allow it to be used with
logind (a claim that I do not agree with - and I think you and Michael are
moving the goalposts by using the existence of bugs in
cgmanager+systemd-shim /in general/ as a justification for delaying the
change in dependency order), then those bugs should be marked as
release-critical, and the determination should be made by the usual means
whether systemd-shim should be included in the release.  But it is not for
the systemd maintainers to exercise a veto on systemd-shim outside of our
normal process for deciding that packages are RC-buggy.

> Nonetheless, as far as I can tell, libpam-systemd is *not* the package
> driving the systemd transition anymore.  Does that address your concern,
> Russ?

It absolutely does not address the problem, because if it weren't driving
the systemd transition in at least some cases (and it is), *there would be
no reason not to list systemd-shim as the first alternative*.

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

[1] For the record, this is not my position.  I understand Russ's concerns,
but I also think the grub transition is as much an example of the *problems*
with such an approach as it is of the successes, because at the end of the
day users are still left to manually switch away from grub1 - many of whom
never have, and have wound up with more bugs over the long term as a result
of using EOLed software.  We should take care that our users' upgrade
experience is a good one, but there are downsides to a policy of never
making a change on upgrade that we haven't 100% proven won't result in boot

Attachment: signature.asc
Description: Digital signature

Reply to: