On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote: > On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery <email@example.com> 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, 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 | systemd-shim. 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/ firstname.lastname@example.org email@example.com  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.
Description: Digital signature