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 <vor...@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 <vor...@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 <r...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
