Bug#746578: Reasons to keep systemd-sysv as the first alternative
I'd like to call attention to a few reasons why libpam-systemd should continue to depend on systemd-sysv | systemd-shim. First, see bugs like 761389 (and others on cgmanager and systemd-shim), which are still popping up regularly. While I acknowledge that people are actively working on the shim stack, far fewer people work on or test that stack (or have a reason to care about that stack) than on the systemd stack, and that stack is continuously playing catch-up based on new systemd development. As a result, it will inevitably encounter more issues than the systemd stack. That's not an argument to drop that stack, but it *is* an argument to not make it the default. I don't think it's reasonable to consider the shim stack a more natural change from sysvinit; people argue for sysvinit based on legacy/maturity/etc, but the shim stack introduces a significant amount of new machinery with far *less* maturity, legacy, or testing than sysvinit *or* systemd. Second, the technical committee *already* decided to make systemd the default init system. This seems like yet another attempt to seize an opportunity to erode or undermine that decision. (I anticipate many more such attempts in the future.) The technical committee decision did not say default only for new installs, with upgrades using sysvinit, for instance. Third, there's already a proposal on -devel to detect potentially problematic situations on upgrade (such as hand-edited /etc/init.d scripts that would be superseded by un-edited .service files), and prompt in that situation. Such a prompt would be similar to the existing prompts obtained when attempting to remove the package for the running kernel; they're not the most elegant approach around, but they'd address many of the concerns regarding more intricate sysvinit setups that would need manual intervention for a smooth upgrade. That would then avoid introducing a prompt for *all* systems, even those that can smoothly upgrade with no issues. I would advocate for implementing the prompting proposal, and keeping systemd-sysv as the first (preferred) alternative in libpam-systemd's dependencies. (Though, if a one-time unconditional prompt about upgrading to systemd would serve as suitable warning, I'd advocate for that; however, somehow I doubt that step would actually satisfy people calling for systemd's head.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918153431.GA14232@thin
Bug#746578: Reasons to keep systemd-sysv as the first alternative
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. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87iokkyf5d@hope.eyrie.org
Bug#746578: Reasons to keep systemd-sysv as the first alternative
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, not least of which because that would mean systems with desktops or certain daemon packages installed would get transitioned to systemd but other systems would not. However, as far as I can tell, I think we've actually solved that problem: wheezy systems with sysvinit installed will upgrade to the transitional sysvinit package, which depends on init, which depends on systemd-sysv | sysvinit-core | upstart. Between that and init being Essential: yes (which causes apt to try to install it on all upgrades to jessie), that *should* cause a transition to systemd-sysv. Now, that's not quite optimal yet. Michael Biebl is currently working on a plan to have fallback boot options available in GRUB that will boot to sysvinit when both are installed, and that would require having both systemd-sysv and some sysvinit package (not clear which one) installed. (This could support other bootloaders as well, and systems not explicitly covered could still explicitly boot with init=/lib/sysvinit/init on the kernel command line.) Nonetheless, as far as I can tell, libpam-systemd is *not* the package driving the systemd transition anymore. Does that address your concern, Russ? - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918183435.GA2380@jtriplet-mobl1
Bug#746578: Reasons to keep systemd-sysv as the first alternative
On Thu, Sep 18, 2014 at 11:36:53AM -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, not least of which because that would mean systems with desktops or certain daemon packages installed would get transitioned to systemd but other systems would not. However, as far as I can tell, I think we've actually solved that problem: wheezy systems with sysvinit installed will upgrade to the transitional sysvinit package, which depends on init, which depends on systemd-sysv | sysvinit-core | upstart. Between that and init being Essential: yes (which causes apt to try to install it on all upgrades to jessie), that *should* cause a transition to systemd-sysv. Now, that's not quite optimal yet. Michael Biebl is currently working on a plan to have fallback boot options available in GRUB that will boot to sysvinit when both are installed, and that would require having both systemd-sysv and some sysvinit package (not clear which one) installed. (This could support other bootloaders as well, and systems not explicitly covered could still explicitly boot with init=/lib/sysvinit/init on the kernel command line.) Correction to this part of my mail: /lib/sysvinit/init is provided by the sysvinit package, which will remain installed in an upgrade from wheezy to jessie. So, this already works, apart from the automatic entries in the grub bootloader. My apologies for suggesting that there was more to do there in terms of package dependencies. I just tested this by installing a wheezy minbase chroot with debootstrap and upgrading it to jessie. This installed systemd-sysv via init, left sysvinit installed, and /lib/sysvinit/init existed for use as a fallback init. At no time was libpam-systemd installed. Nonetheless, as far as I can tell, libpam-systemd is *not* the package driving the systemd transition anymore. Does that address your concern, Russ? - Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918185054.GA9424@jtriplet-mobl1
Bug#746578: More systemd fallout :-/
On Wed, 17 Sep 2014 15:34:48 +0100 Ian Jackson ijack...@chiark.greenend.org.uk wrote: In #746578, a user requests that the dependency from libpam-systemd to systemd be changed from systemd-sysv | systemd-shim to systemd-shim | systemd-sysv The maintainers of libpam-systemd have rejected this change. I would like the TC to set out the applicable principle(s), and overrule the maintainer in this case. As I understand it from reading the threads in the bug and on debian-devel, the effect of this would be: * New jessie installations would still get systemd. * squeeze-jessie upgrades which are not already using systemd would not be switched silently to systemd but would use systemd-shim instead. * Attempts to upgrade non-systemd systems in some other circumstances would no longer switch silently to systemd. The latter two points are not actually accurate. I just tested this by installing a wheezy minbase chroot using debootstrap and upgrading it to jessie. The list of packages installed as part of the wheezy minbase chroot: apt base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname initscripts insserv libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0 libc-bin libc6 libcomerr2 libdb5.1 libgcc1 liblocale-gettext-perl liblzma5 libmount1 libncurses5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libss2 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libtinfo5 libusb-0.1-4 libustr-1.0-1 libuuid1 login lsb-base mawk mount multiarch-support ncurses-base ncurses-bin passwd perl-base readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar tzdata util-linux xz-utils zlib1g The upgrade: /# apt-get --no-install-recommends dist-upgrade Reading package lists... Done Building dependency tree... Done Calculating upgrade... Done The following NEW packages will be installed: acl adduser dmsetup gcc-4.9-base init libaudit-common libaudit1 libcap2 libcap2-bin libcryptsetup4 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper1.02.1 libgcrypt11 libgcrypt20 libgpg-error0 libkmod2 libncursesw5 libpcre3 libprocps3 libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libudev1 libwrap0 procps startpar systemd systemd-sysv udev The following packages will be upgraded: apt base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname initscripts libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0 libc-bin libc6 libcomerr2 libgcc1 liblocale-gettext-perl libmount1 libncurses5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libss2 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtinfo5 libusb-0.1-4 libuuid1 login lsb-base mount multiarch-support ncurses-base ncurses-bin passwd perl-base readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar tzdata util-linux zlib1g 70 upgraded, 31 newly installed, 0 to remove and 0 not upgraded. Need to get 33.7 MB of archives. After this operation, 27.5 MB of additional disk space will be used. (Including recommends would install a few additional packages, including libpam-systemd because systemd Recommends it, but I used --no-install-recommends to prove that libpam-systemd was *not* the driver of the transition, nor was it involved in the upgrade.) This transition is driven not by libpam-systemd as suggested in this bug report, but by the sysvinit transitional package (which depends on init) and by moving the Essential: yes bit from sysvinit to init. Note that that transition was coordinated between the sysvinit, systemd, and upstart maintainers, and that the init package also supports sysvinit and upstart. The sysvinit transitional package additionally provides sysvinit itself via /lib/sysvinit/init, making it possible to boot sysvinit via init=/lib/sysvinit/init even with systemd-sysv installed. Michael Biebl is working on automatically adding a GRUB menu entry to boot sysvinit if present, which would make that even smoother. Hope that helps, Josh Triplett -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918185901.GA9801@jtriplet-mobl1
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 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. 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@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. signature.asc Description: Digital signature
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 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
Bug#746578: Reasons to keep systemd-sysv as the first alternative
On Thu, 2014-09-18 at 12:23 -0700, Steve Langasek wrote: On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote: 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. He did give *technical* reasons to not invert the dependency. I also agree that it's suboptimal if the init system changes as a side effect of upgrading/installing some other, seemingly unrelated, package. However, that does not make it a good idea to install shim as a side effect instead. At least the case where you do partial upgrades of packages that now add a libpam-systemd dependency is one where systemd-sysv first seems technically correct (more below). When doing partial upgrades, I think the ideal user experience would be to inform the user that he should do the migration to systemd at this point before proceeding to update certain individual packages to newer versions. 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. It is also relevant if someone does a partial upgrade to current unstable from an older system that still uses sysvinit for legacy reasons only (and is expected to switch to systemd at *some* point in any case). Installing shim would make the user waste effort dealing with shim's problems, while still requiring them to deal with any incompatibilities from the systemd transition at a later point. Deferring some issues in this way while increasing the amount of overall work and problems could be a valid choice in particular cases, but I do not thing it should be the default behavior. 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 There is a difference between a package that's functional enough to be useful for people who know what they're doing, and a package that's suitable to be automatically installed just because people do partial upgrades in a particular order. And it seems that systemd-shim falls in the first camp (though I have not followed it closely myself). It may not be RC-buggy, but not RC-buggy is not a sufficient quality criterion to install it automatically if a user just wants newer GNOME packages for example. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1411076173.1645.3.ca...@pp1.inet.fi
Bug#746578: Reasons to keep systemd-sysv as the first alternative
On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett j...@joshtriplett.org wrote: 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. To be more precise, it would be !systemd-sysv ? systemd-shim : systemd-sysv so that other alternate inits are treated equally. As you hopefully can see, this can be condensed to systemd-sysv ? systemd-sysv : systemd-shim AKA systemd-shim | systemd-sysv :) One question: if `init` and `libpam-systemd` (with the inversed dependency) are installed simultaneously on a system with only sysvinit installed (i.e. Wheezy), apt would know that systemd-sysv is going to be installed (to satisfy init package's dependency) and would not install systemd-shim, correct? Although, according to Steve that would be simply an aesthetic issue, as systemd-shim does not impede operation of systemd as init. Best regards, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CALZWFR+DKFwoR=dcarpea5czesyiaupywuwuoa+nmpdjf8l...@mail.gmail.com
Bug#746578: More systemd fallout :-/
On Thu, Sep 18, 2014 at 11:59 AM, Josh Triplett j...@joshtriplett.org wrote: On Wed, 17 Sep 2014 15:34:48 +0100 Ian Jackson ijack...@chiark.greenend.org.uk wrote: In #746578, a user requests that the dependency from libpam-systemd to systemd be changed from systemd-sysv | systemd-shim to systemd-shim | systemd-sysv The maintainers of libpam-systemd have rejected this change. I would like the TC to set out the applicable principle(s), and overrule the maintainer in this case. As I understand it from reading the threads in the bug and on debian-devel, the effect of this would be: * New jessie installations would still get systemd. * squeeze-jessie upgrades which are not already using systemd would not be switched silently to systemd but would use systemd-shim instead. * Attempts to upgrade non-systemd systems in some other circumstances would no longer switch silently to systemd. The latter two points are not actually accurate. I just tested this by installing a wheezy minbase chroot using debootstrap and upgrading it to jessie. The list of packages installed as part of the wheezy minbase chroot: apt base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname initscripts insserv libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0 libc-bin libc6 libcomerr2 libdb5.1 libgcc1 liblocale-gettext-perl liblzma5 libmount1 libncurses5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libss2 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libtinfo5 libusb-0.1-4 libustr-1.0-1 libuuid1 login lsb-base mawk mount multiarch-support ncurses-base ncurses-bin passwd perl-base readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar tzdata util-linux xz-utils zlib1g The upgrade: /# apt-get --no-install-recommends dist-upgrade Reading package lists... Done Building dependency tree... Done Calculating upgrade... Done The following NEW packages will be installed: acl adduser dmsetup gcc-4.9-base init libaudit-common libaudit1 libcap2 libcap2-bin libcryptsetup4 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper1.02.1 libgcrypt11 libgcrypt20 libgpg-error0 libkmod2 libncursesw5 libpcre3 libprocps3 libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libudev1 libwrap0 procps startpar systemd systemd-sysv udev The following packages will be upgraded: apt base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname initscripts libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0 libc-bin libc6 libcomerr2 libgcc1 liblocale-gettext-perl libmount1 libncurses5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libss2 libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtinfo5 libusb-0.1-4 libuuid1 login lsb-base mount multiarch-support ncurses-base ncurses-bin passwd perl-base readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar tzdata util-linux zlib1g 70 upgraded, 31 newly installed, 0 to remove and 0 not upgraded. Need to get 33.7 MB of archives. After this operation, 27.5 MB of additional disk space will be used. (Including recommends would install a few additional packages, including libpam-systemd because systemd Recommends it, but I used --no-install-recommends to prove that libpam-systemd was *not* the driver of the transition, nor was it involved in the upgrade.) This transition is driven not by libpam-systemd as suggested in this bug report, but by the sysvinit transitional package (which depends on init) and by moving the Essential: yes bit from sysvinit to init. Note that that transition was coordinated between the sysvinit, systemd, and upstart maintainers, and that the init package also supports sysvinit and upstart. If the transition is already happening, why have the dependency be like it is anyway? User's systems will be switched regardless, so there is no use in having a second pass at changing the init. Also, although the squeeze/wheezy - jessie bit Ian wrote seems to be incorrect, his last point still stands: on a jessie minbase (with init shifted to !systemd-sysv), if you install libpam-systemd, your init is changed back to systemd. So the systemd-sysv | systemd-shim bit is either pointless and redundant (upgrading to Jessie) or actively disruptive (installation of libpam-systemd on jessie+ systems). Cheers, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:
