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 | 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/ 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 regressions.
Attachment:
signature.asc
Description: Digital signature