Bug#746578: Reasons to keep systemd-sysv as the first alternative
I'm pulling a quote from the bottom of Steve's mail to the top, to call
attention to a new and critical point that I didn't see raised anywhere
in the debian-devel discussion:
On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek <vorlon@debian.org> wrote:
> If we decide that init *should* be automatically changed on upgrade, then
(Which I'm assuming from your footnote [1] that you *are* in favor of?)
> 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.
*This* is a point that I haven't seen raised in the entire previous
discussion on debian-devel, and I think it's a completely valid point.
Personally, in this case, I'd argue that the desirable dependency (which
we can't easily express) would be "sysvinit-core ? systemd-shim :
systemd-sysv". In other words, "if the user has explicitly selected
sysvinit, as indicated by installing the sysvinit-core package that only
exists in jessie but not wheezy, then install systemd-shim to make that
work, otherwise use systemd-sysv". That's not equivalent to either
libpam-systemd's current dependencies *or* your proposal to invert them.
If there's a way to express *that* dependency through the dependency
mechanism we currently have, I'd be entirely in favor of it; if a user
has explicitly selected sysvinit-core, as opposed to implicitly by
having sysvinit installed, then by all means they should end up with
sysvinit-core plus systemd-shim rather than systemd-sysv.
However, that said, if flipping the dependencies around (together with
the current sysvinit and init packages) would best approximate that,
without breaking any of the upgrade or new-install cases, then I'd be
happy to drop my objection to changing libpam-systemd's dependencies.
Specifically, are the following all true even with libpam-systemd's
dependencies inverted? (Ideally it would help to test this via
debootstrap and apt.)
- Upgrades from wheezy to jessie, with or without a desktop environment
installed, will transition from sysvinit to systemd-sysv, via the
init/sysvinit packages (the latter providing /lib/sysvinit/init).
- New installs of jessie via d-i or debootstrap, with or without
task-desktop or gnome, will install systemd-sysv. (d-i is the
important case, but I'm concerned about the deboostrap case because I
don't know if apt would be smart enough to look at the *simultaneous*
installation of init and libpam-systemd and favor init's preference of
systemd-sysv over libpam-systemd's preference of systemd-shim. I
don't think d-i installs those simultaneously.)
- As you suggested below, installs of jessie that have explicitly
switched to sysvinit (or upstart for that matter) and subsequently
installed a package depending on libpam-systemd should install
systemd-shim rather than systemd-sysv.
If all three of the above are true with init and sysvinit staying as
they are and libpam-systemd's dependencies switching around, then I
don't see any harm in switching the dependencies around, and I'll stop
advocating against that. If any of the above would be broken with
libpam-systemd's dependencies inverted, then I'd advocate against
changing those dependencies for exactly that reason.
Ideally, I'd like to keep this part of the discussion (regarding Steve's
very reasonable point below that users who *explicitly* install
sysvinit-core in jessie should not be switched to systemd-sysv by
installing a desktop environment) separate from the question of whether
upgrades from wheezy to jessie should switch from sysvinit to
systemd-sysv (which as far as I can tell Steve is not objecting to, but
Ian is).
On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek <vorlon@debian.org> wrote:
> 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.
No, that's not true at all, even if you consider the existing change of
our default as political. I'm arguing that libpam-systemd should remain
1) consistent with the essential "init" package, which *also* defaults
to systemd-sysv; 2) consistent with the agreed-upon switch to systemd as
the new default; and 3) consistent with the literal meaning of
alternative and preferred dependencies, "prefer systemd-sysv by default
but allow systemd-shim as an alternative". See the list of new-install
and upgrade cases earlier in this mail for the specific technical cases
I'm concerned about.
> 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.
Those are two separate issues.
If systemd-shim or cgmanager is broken, it shouldn't be listed as an
alternative dependency at all, let alone as the first alternative. That
was the case during the period before systemd-shim and cgmanager got
updated to support acting as an alternative to systemd >= 204. However,
since systemd-shim is currently installable, listing systemd-shim as a
non-default alternative makes it easier for people in unstable to test
it and find/file/fix bugs, as well as stemming the large tide of
unproductive rants produced during that period.
*Separately* from that, there's the question of switching init on
upgrades. On that front, libpam-systemd *used* to be the package
driving such upgrades, but it no longer is; that's now driven by the
"sysvinit" transitional package and the "init" package. So, changing
libpam-systemd's dependencies should hopefully have absolutely no effect
on the sysvinit -> systemd transition, unless apt is buggy somehow in a
non-obvious way. Hence my comments above about the cases we care about.
> 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.
Not disputing that point, though per your footnote [1] you're not
actually advocating that.
> The way to accomplish
> this is to list systemd-shim as the first alternative dep.
That would not be sufficient; you would also need to change the "init"
package if you didn't want the transition to happen. Changing
libpam-systemd alone will not have any useful effect on upgrades, and it
would be helpful to test whether it would have a detrimental effect on
upgrades.
> > 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*.
I was specifically asking if it addressed the concerns Russ raised in
his mail; I agree that it doesn't address the new point you made in your
mail.
I appreciate you raising the case of explicitly installing sysvinit-core
and subsequently installing a DE that depends on libpam-systemd. That
case seems quite separate from the cases involving installs or upgrades
to jessie, and the motivation for changing the dependencies of
libpam-systemd make much more sense now.
On that note, I'd suggest retitling this bug.
> [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
> regressions.
This is my concern as well. I want to make sure we switch the users who
don't care about init systems one way or another; I really don't care
about attempting to force a switch on the users who actively *want*
sysvinit-core for whatever reason. If we don't switch upgrades to match
the default, then we'll end up failing to switch a large number of
users, including many of our less experienced users.
- Josh Triplett
Reply to: