Bug#762194: Call for Votes (re automatic switching)
Keith Packard writes (Re: Bug#762194: Call for Votes (re automatic switching)): I vote Y, FD Thanks everyone. With Keith's vote, the outcome is no longer in doubt: Y,FD: Ian, Russ, Andreas, Don, Keith FD,Y: Steve Y wins. Don, shall I send a message to d-d-a ? I think the bug needs to remain open as we haven't actually resolved it yet. Ian. -- 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/21592.53058.999787.593...@chiark.greenend.org.uk
Bug#762194: [CTTE #762194] On automatic init system switching on upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The technical committee was asked in #762194 whether existing systems should be automatically switched to systemd during a dist-upgrade to jessie: RESOLUTION 0. We offer advice and make our views known (Constitution 6.1(5)): 1. The Technical Committee decision in February, selecting systemd as the default init system for Linux, should not be read as a decision that existing systems should be automatically switched to systemd. 2. The Technical Committee has been asked to decide whether existing Debian GNU/Linux systems should be automatically switched to systemd during a dist-upgrade to jessie. 3. We do not want to prejudge, interfere with, or contradict, the General Resolution process on init systems which is currently ongoing. Some of the GR options imply that automatic switching (both during upgrades, and during leaf package installations) will be necessary in at least some circumstances. 4. For the moment, we invite concrete proposals for technical changes which would arrange that 1. new jessie installations using Linux would get systemd but 2. existing installations retain their existing init system so far as possible. 5. After the result of the General Resolution is known, we intend to formally resolve the question of automatic switching of init systems. Our decision on that question will of course be consistent with the successful General Resolution option, whatever that may be. END OF RESOLUTION The committee would like to thank everyone who participated in the discussion of #762194. Please see http://bugs.debian.org/762194 for discussion of this bug. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUWO5jAAoJEOPjOSNItQ05bYsIAJoNahPzID0Dxuz5M2eO9qau 8f4RzORcgpqsqg0s8+k0KtG4RSYy3ONqKRENuRvM3LWDaAN1YncCnzNjHqhvwh6b 1s5MnDNSOhh6s1Em9n4BW0eCowXeG6oaNacBNjcUQlr0MqgFyA25FKuYnKDlSKIP 2sxE6PfPUk/GRosd/+QZ3HqIa52a0jzFFshWUCKrV5WiftMES63CsjIurHCWowGR MCEYuG3qENZ4hEj78GGCPxRoJXDF72WAtJv22tPrzIboOvenzkAXFcxKhE+cCes+ ba22wxbWXSPEnvFHnhKFrzDy/2A6ixSg9JUK3u0SRUgyclK++2AIl/r4RCLdPbo= =BbXP -END PGP SIGNATURE- -- 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/21592.61064.527547.410...@chiark.greenend.org.uk
Bug#762194: Call for Votes (re automatic switching)
Ian Jackson writes (Bug#762194: Call for Votes (re automatic switching)): Don, shall I send a message to d-d-a ? I think the bug needs to remain open as we haven't actually resolved it yet. I have sent the mail to d-d-a, as you'll see. I used Don's last one as a template. Thanks, all. Ian. -- 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/21592.61567.483816.564...@chiark.greenend.org.uk
Bug#746578: libpam-systemd to flip dependencies - proposal
On Tue, Nov 04, 2014 at 07:47:05AM +0100, Christian Seiler wrote: Am 02.11.2014 06:59, schrieb Josh Triplett: Apart from that, I would still request that someone with the ability to produce a modified local mirror test the two critical cases mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#129 . If those two cases work, then systemd systems should not end up with systemd-shim installed under normal circumstances, making breakage far less likely. debootstrap 1.0.64 on a current Jessie box with a locally modified and otherwise up-to-date (2014-11-04T05:00Z) mirror wants to pull in the following packages[1]: [...snip list in favor of diff...] [1] debootstrap --print-debs --no-check-gpg \ --include=libpam-systemd jessie $DIR $MIRROR PS: Diff of the stuff that is pulled in compared to the same command done in the current archive (after sorting the package list): @@ -7,6 +7,7 @@ bash bsdmainutils bsdutils +cgmanager coreutils cpio cron @@ -57,6 +58,7 @@ libcap2-bin libcap-ng0 libc-bin +libcgmanager0 libcomerr2 libcryptsetup4 libdb5.3 @@ -70,6 +72,7 @@ libgcc1 libgcrypt20 libgdbm3 +libglib2.0-0 libgmp10 libgnutls-deb0-28 libgnutls-openssl27 @@ -94,6 +97,8 @@ libnettle4 libnewt0.52 libnfnetlink0 +libnih1 +libnih-dbus1 libp11-kit0 libpam0g libpam-modules @@ -153,6 +158,7 @@ sensible-utils startpar systemd +systemd-shim systemd-sysv sysvinit-utils sysv-rc I've also tried debootstrap 1.0.62 on a Fedora 19 box with the same mirror, with the same results. Note that systemd-shim together with cgmanager is pulled in. Thank you very much for the careful testing and analysis! This result concerns me greatly, and I think the technical committee should take this into account when considering whether to flip the dependencies of libpam-systemd around. I find it odd that debootstrap produced this result, and I've filed a bug on debootstrap about this, but in any case, with current debootstrap, flipping the libpam-systemd dependencies around will result in installing systemd-shim (but not any non-systemd init that needs it) on systemd systems. Given past bugs in both systemd-shim and cgmanager that broke systemd, that seems less than ideal. (Not utterly unreasonable, but it introduces an entirely unnecessary additional source of potential problems.) This isn't a complete showstopper, since most of the time people seem to debootstrap a standard system and then install additional packages. However, it would affect a debootstrap with --include=task-desktop or --include=gnome or similar. Does anyone see an obvious way to structure the dependencies to avoid this result and only install systemd-sysv? If no way exists, it might be worth making sure jessie's debootstrap gets fixed in time. My guess is that there's some greediness in the dependency resolver in debootstrap, and as long as there's no conflict, it won't try to follow other alternatives to see if the dependencies have already been met. Also note that neither --exclude=systemd-shim,cgmanager nor --exclude=systemd-shim seem to have no effect whatsoever on the list of packages. (Which is probably a bug in debootstrap, because it should at least warn you if it can't fulfill the specified --exclude, but also in this case it could actually exclude it...) I've filed a bug on debootstrap for these two issues. I haven't tested the upgrade scenario. I appreciate the test you already ran. I'd love to see an upgrade test as well (from a system with sysvinit installed), but this test already revealed an issue. - 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/20141104160726.GA5844@thin
Bug#746578: libpam-systemd to flip dependencies - proposal
Josh Triplett j...@joshtriplett.org writes: This result concerns me greatly, and I think the technical committee should take this into account when considering whether to flip the dependencies of libpam-systemd around. So, this came up before, and I believe that systemd-shim is not supposed to interfere with systemd with the current version. In other words, I think the existence of the package on the system should be a no-op if the system is booted with systemd. That makes this a minor bug, but not something that's too serious. Am I wrong about this? -- 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/87wq7arjng@hope.eyrie.org
Bug#746578: libpam-systemd to flip dependencies - proposal
I've been reading the messages from Josh about cgmanager etc., and they haven't changed my mind about the need to flip these dependencies. If other bugs in systemd-ship or cgmanager turn up, they should be fixed. We have time to do that. And I am not opposed to further `safety' changes to cgmanager. Those should be discussed with the appropriate maintainer. So, I hereby formally propose the resolution text below. I intend to call for votes some time tomorrow. Thanks, Ian. === Rationale (Constitution 6.1(5)): 1. Currently libpam-systemd (which is pulled in by quite a few dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'. 2. The effect of this is that installing some packages which depend (directly or indirectly) on libpam-systemd can cause a user's init system to be switched to systemd, even on systems where a user has deliberately chosen not to use the default init system, and even when the switch is unnecessary. 3. Swappping the order of these dependencies would avoid that and has no harmful effect: 4. In particular, on systems that already have systemd-sysv installed, libpam-systemd will still not pull in systemd-shim, thus minimizing the risk of breakage on systemd systems. However, on systems that intentionally do not have systemd installed, the installation of libpam-systemd will then prefer to pull in systemd-shim and keep the installed init system rather than switching to systemd-sysv. Decision (Constitution 6.1(4)): 5. We therefore overrule the decision of the maintainer of libpam-systemd binary package. The Depends entry systemd-sysv | systemd-shim (= 8-2) should be replaced by systemd-shim (= 8-2) | systemd-sysv 6. For the avoidance of doubt, we do not intend to set this specific syntax in stone. For example, if in future libpam-systemd needs to depend on a later systemd-shim, or needs a versioned rather than unversioned dependency on systemd-sysv, that is fine and would not contradict our decision. Release (Constitution 6.1(5)): 7. Our advice is that this change should be in jessie. If necessary, this view should be conveyed to the Release Team, after the change is in unstable, by filing an unblock request in the usual way. === -- 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/21593.4845.379787.20...@chiark.greenend.org.uk
Bug#746578: libpam-systemd to flip dependencies - proposal
Am 04.11.2014 17:07, schrieb Josh Triplett: This isn't a complete showstopper, since most of the time people seem to debootstrap a standard system and then install additional packages. However, it would affect a debootstrap with --include=task-desktop or --include=gnome or similar. Just as a side note: I never use debootstrap to actually include anything that wouldn't be considered 'base system', just because I've had the experience that quite a few packages don't work together with debootstrap (try doing --include=syslog-ng (and --exclude=rsyslog) while debootstrapping wheezy - the dependency resolution works properly, but the package won't install, because the preinst or postinst scripts don't like debootstrap's environment (the rsyslog exclude alone works btw., so that's what I'm doing if I want something with syslog-ng)). I have some real doubts that debootstrap is going to be able to set up something like GNOME or task-desktop or whatever, just because they probably are going to pull in lots of packages of which at least a couple are going to have similar problems to the aforementioned one I had with syslog-ng. Therefore, I always tend to use debootstrap to just install a very, very basic system and then use apt-get in a chroot to install the rest of the software, if I decide to install a Debian image like that. This in mind, looking at apt-cache rdepends libpam-systemd[1], I don't see anything in there I'd want to include in debootstrap. But maybe that's just me. Does anyone see an obvious way to structure the dependencies to avoid this result and only install systemd-sysv? I don't think that's possible if you want to keep the effect the switching the dependencies has (i.e. selecting systemd-shim as first alternative so that systems without systemd as pid1 don't try to install systemd-sysv when packages depending on logind are installed). I haven't tested the upgrade scenario. I appreciate the test you already ran. I'd love to see an upgrade test as well (from a system with sysvinit installed), but this test already revealed an issue. - Fresh install of Debian Wheezy (from netinst CD) - tasksel: Standard utilities + SSH server - aptitude full-upgrade - aptitude install --without-recommends gdm3 (package that pulls in libpam-systemd in Jessie, without installing too much, although gdm3 itself already pulls in quite a lot on wheezy, in hindsight probably should have gone with network-manager...) - Then edit sources.list, remove everything wheezy-related, add my modified mirror, apt-get update Then this gives the following consequences: - apt-get upgrade: * doesn't try to upgrade enough packages that you could call the system jessie, doesn't pull in anything systemd related other than trying to upgrade libsystemd-login0 (already installed on wheezy because of a Depends of dbus) - apt-get dist-upgrade * pulls in systemd-shim - aptitude full-upgrade * pulls in systemd-shim - aptitude upgrade (i.e. safe-upgrade) * takes a couple of minutes to resolve deps (granted, running in a VM, but I have a fast CPU, so this is really unusual, never seen aptitude working so long before, but OTOH I've never done a dist-upgrade with aptitude before, so maybe that's normal?) * DOES NOT pull in systemd-shim - didn't test any other frontends (I'm not showing any detailed package lists here because there's just too much unrelated stuff.) Christian [1] Depended on by: udisks2, policykit-1, network-manager, lightdm*, gnome-settings-daemon, gnome-bluetooth, gdm3 Recommended by (not relevant for deboostrap IIRC): xfce4-session, xfce4-power-manager, systemd, gnome-session-bin, argyll (* Depends: libpam-systemd | consolekit) PS: I tested this because I think it's better to have all the relevant information before deciding an issue, please don't interpret my email as being critical of the proposed resolution. -- 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/54592660.5000...@iwakd.de
Bug#746578: libpam-systemd to flip dependencies - proposal
On Tue, Nov 04, 2014 at 08:17:52PM +0100, Christian Seiler wrote: Am 04.11.2014 17:07, schrieb Josh Triplett: This isn't a complete showstopper, since most of the time people seem to debootstrap a standard system and then install additional packages. However, it would affect a debootstrap with --include=task-desktop or --include=gnome or similar. Just as a side note: I never use debootstrap to actually include anything that wouldn't be considered 'base system', just because I've had the experience that quite a few packages don't work together with debootstrap (try doing --include=syslog-ng (and --exclude=rsyslog) while debootstrapping wheezy - the dependency resolution works properly, but the package won't install, because the preinst or postinst scripts don't like debootstrap's environment (the rsyslog exclude alone works btw., so that's what I'm doing if I want something with syslog-ng)). I have some real doubts that debootstrap is going to be able to set up something like GNOME or task-desktop or whatever, just because they probably are going to pull in lots of packages of which at least a couple are going to have similar problems to the aforementioned one I had with syslog-ng. Therefore, I always tend to use debootstrap to just install a very, very basic system and then use apt-get in a chroot to install the rest of the software, if I decide to install a Debian image like that. This in mind, looking at apt-cache rdepends libpam-systemd[1], I don't see anything in there I'd want to include in debootstrap. But maybe that's just me. No, I agree with you; it doesn't seem excessively problematic by itself, and it may or may not actually be a good argument against the proposed resolution. Does anyone see an obvious way to structure the dependencies to avoid this result and only install systemd-sysv? I don't think that's possible if you want to keep the effect the switching the dependencies has (i.e. selecting systemd-shim as first alternative so that systems without systemd as pid1 don't try to install systemd-sysv when packages depending on logind are installed). Well, one obvious approach: make either systemd-shim or cgmanager Conflicts: systemd-sysv. However, that seems overly harsh, and breaks the case of booting an alternate init system via the init= command-line argument. I haven't tested the upgrade scenario. I appreciate the test you already ran. I'd love to see an upgrade test as well (from a system with sysvinit installed), but this test already revealed an issue. - Fresh install of Debian Wheezy (from netinst CD) - tasksel: Standard utilities + SSH server - aptitude full-upgrade - aptitude install --without-recommends gdm3 (package that pulls in libpam-systemd in Jessie, without installing too much, although gdm3 itself already pulls in quite a lot on wheezy, in hindsight probably should have gone with network-manager...) - Then edit sources.list, remove everything wheezy-related, add my modified mirror, apt-get update Then this gives the following consequences: - apt-get upgrade: * doesn't try to upgrade enough packages that you could call the system jessie, doesn't pull in anything systemd related other than trying to upgrade libsystemd-login0 (already installed on wheezy because of a Depends of dbus) - apt-get dist-upgrade * pulls in systemd-shim - aptitude full-upgrade * pulls in systemd-shim - aptitude upgrade (i.e. safe-upgrade) * takes a couple of minutes to resolve deps (granted, running in a VM, but I have a fast CPU, so this is really unusual, never seen aptitude working so long before, but OTOH I've never done a dist-upgrade with aptitude before, so maybe that's normal?) * DOES NOT pull in systemd-shim - didn't test any other frontends Well, ugh. Bad apt, no biscuit. This seems much more problematic to me. I *expected* apt to say well I need to install the Essential init package, which pulls in systemd-sysv, which satisfies libpam-systemd. But apparently apt resolved all the dependencies simultaneously and ignored alternative dependencies. (Presumably if you had systemd-sysv installed in wheezy this wouldn't happen, but that's not an interesting case, nor does it need this kind of test to confirm that.) I wouldn't necessarily suggest using this as an argument against the proposed resolution. Instead, I'd recommend making sure that cgmanager is just as harmless under systemd as systemd-shim 8-4 currently is, by making it not run under systemd. That would make this change much safer. PS: I tested this because I think it's better to have all the relevant information before deciding an issue, please don't interpret my email as being critical of the proposed resolution. Thank you *very* much for your work. - Josh
Bug#746578: libpam-systemd to flip dependencies - proposal
josh == josh j...@joshtriplett.org writes: josh I wouldn't necessarily suggest using this as an argument josh against the proposed resolution. Instead, I'd recommend josh making sure that cgmanager is just as harmless under systemd josh as systemd-shim 8-4 currently is, by making it not run under josh systemd. That would make this change much safer. I think making cgmanager not run by default under systemd seems reasonable. However, as we've seen discussed on -vote cgmanager provides different services than systemd and if you need full semantics can do things systemd cannot do. For that reason, I can see people wanting to use it along-side systemd. I'd discourage the TC from making a ruling about cgmanager and encourage the cgmanager maintainer to find a way to make it not run by default but be enabled at administrator request. -- 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/tslioiu4puz@mit.edu
Bug#746578: libpam-systemd to flip dependencies - proposal
On Tue, 4 Nov 2014 17:54:53 + Ian Jackson ijack...@chiark.greenend.org.uk wrote: I've been reading the messages from Josh about cgmanager etc., and [snip] Actually, I'd like to completely withdraw my concerns there, in light of some new information. Quoting Serge Hallyn, maintainer of cgmanager: Currently the cgmanager sytemd unit is installed inactive, so by default it will not interfere with systemd. The user needs to specifically enable it. So, both systemd-shim and cgmanager seem entirely harmless on systemd systems; the former will not run at all under systemd, and the latter will not run by default under systemd. Based on that, I no longer have any concerns about flipping the dependencies around, even though doing so will likely pull those two packages in on systemd systems per Christian Seiler's detailed analysis. I don't see any obvious further steps that need to occur other than flipping the dependency around. (It might be a good idea for the libpam-systemd dependency to bump its versioned dependency on systemd-shim to (= 8-4), but that's up to the libpam-systemd maintainers.) (This is still orthogonal to any discussions regarding switching on upgrades, or regarding dependencies on systemd.) - Josh Triplett Rationale (Constitution 6.1(5)): 1. Currently libpam-systemd (which is pulled in by quite a few dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'. 2. The effect of this is that installing some packages which depend (directly or indirectly) on libpam-systemd can cause a user's init system to be switched to systemd, even on systems where a user has deliberately chosen not to use the default init system, and even when the switch is unnecessary. 3. Swappping the order of these dependencies would avoid that and has no harmful effect: 4. In particular, on systems that already have systemd-sysv installed, libpam-systemd will still not pull in systemd-shim, thus minimizing the risk of breakage on systemd systems. However, on systems that intentionally do not have systemd installed, the installation of libpam-systemd will then prefer to pull in systemd-shim and keep the installed init system rather than switching to systemd-sysv. Decision (Constitution 6.1(4)): 5. We therefore overrule the decision of the maintainer of libpam-systemd binary package. The Depends entry systemd-sysv | systemd-shim (= 8-2) should be replaced by systemd-shim (= 8-2) | systemd-sysv 6. For the avoidance of doubt, we do not intend to set this specific syntax in stone. For example, if in future libpam-systemd needs to depend on a later systemd-shim, or needs a versioned rather than unversioned dependency on systemd-sysv, that is fine and would not contradict our decision. Release (Constitution 6.1(5)): 7. Our advice is that this change should be in jessie. If necessary, this view should be conveyed to the Release Team, after the change is in unstable, by filing an unblock request in the usual way. === -- 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/20141105010724.GA11065@jtriplet-mobl1
