Bug#746578: libpam-systemd to flip dependencies - proposal
Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - proposal): So, I hereby formally propose the resolution text below. I intend to call for votes some time tomorrow. Thanks again to Josh for all his careful and constructive interventions in the discussion. I'm glad to see that he's now happy with this proposal. I hereby call for votes. There are two options: Y (override, swap dependencies, requires 3:1) FD 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/21594.3801.12361.751...@chiark.greenend.org.uk
Bug#746578: libpam-systemd to flip dependencies - proposal
On Wed, 5 Nov 2014 11:49:45 + Ian Jackson ijack...@chiark.greenend.org.uk wrote: Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - proposal): So, I hereby formally propose the resolution text below. I intend to call for votes some time tomorrow. Thanks again to Josh for all his careful and constructive interventions in the discussion. I'm glad to see that he's now happy with this proposal. This proposal doesn't seem to include the change you made in git commit 227f496617929c48bfd20a9c96eead8b91ee69b7 to fix a typo I reported in item 4: 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. In your mail with Message-ID 21590.30193.479905.710...@chiark.greenend.org.uk, you said: Josh Triplett writes (Bug#746578: libpam-systemd to flip dependencies - proposal): [...] s/intentionally do not have systemd/intentionally do not have systemd-sysv/ Fixed in git. I hereby make that change to my formal proposal. - 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/20141105155158.GA13254@thin
Bug#746578: libpam-systemd to flip dependencies - proposal
On Wed, 05 Nov 2014 08:42:07 -0500 Sam Hartman hartm...@debian.org wrote: I don't think this matters for the vote, and apologies because there's probably a better place to send this advice. I was thinking last night about the apt and debootstrap resolver issues and was wondering whether the following solution might help. I realize the issue is minor and is more about minimizing packages installed than safety of the proposal. What if libpam-systemd depended on systemd-shim-nosysv|systemd-sysv|systemd-shim? Introduce a new package systemd-shim-nosysv in the systemd-shim package that depends on systemd-shim and conflicts with systemd-sysv. I have not tried this. It might reduce the probability that systemd-shim gets uselessly installed. however, I don't know whether it creates systems where systemd-sysv gets removed. Seems like a great idea to me; we talked a bit about Conflicts in the context of cgmanager, but this approach (with an artificial intermediate package) makes much more sense. I agree that it needs careful testing, though; after Christian Seiler's testing of debootstrap and apt, I really don't know how either would decide to resolve this. Either or both might well decide to choose the alternate dependency of the essential init package rather than the alternate dependency of libpam-systemd. Even if this does end up being a good idea, I don't think the TC resolution needs to change. As I read it, the essential character of the resolution is that systemd-shim is preferred to systemd-sysv in libpam-systemd. If we find better technical ways of doing that, more power to us all. If there is a real disagreement about whether we're within the spirit of the TC resolution should it pass, we can ask the TC again either informally or formally. I don't want to see us getting ultra-picky about the wording of resolutions to constrain or permit future innovation. I agree; when I suggested clarifying in the TC decision that the Depends shouldn't be hard-coded (what became clause 6 of the current proposal), I didn't just have versioned dependency changes in mind, but also package structural changes (on either systemd's or systemd-shim's part). I think the suggestion you made above fits entirely within the spirit of the TC resolution. - 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/20141105155932.GA13240@thin
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
Bug#746578: libpam-systemd to flip dependencies - proposal
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]: acl adduser base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n debianutils diffutils dmsetup dpkg e2fslibs e2fsprogs findutils gcc-4.8-base gcc-4.9-base grep gzip hostname init init-system-helpers initscripts insserv libacl1 libattr1 libaudit-common libaudit1 libblkid1 libbz2-1.0 libc-bin libc6 libcap2 libcap2-bin libcomerr2 libcryptsetup4 libdb5.3 libdebconfclient0 libdevmapper1.02.1 libgcc1 libgcrypt20 libgdbm3 libgpg-error0 libkmod2 liblocale-gettext-perl liblzma5 libmount1 libncurses5 libncursesw5 libpam-modules libpam-modules-bin libpam-runtime libpam0g libpcre3 libprocps3 libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libsmartcols1 libss2 libsystemd0 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libtinfo5 libudev1 libustr-1.0-1 libuuid1 login lsb-base mawk mount multiarch-support ncurses-base ncurses-bin passwd perl perl-base perl-modules procps sed sensible-utils startpar systemd systemd-sysv sysv-rc sysvinit-utils tar tzdata udev util-linux zlib1g apt apt-utils bsdmainutils cgmanager cpio cron dbus debian-archive-keyring dmidecode gnupg gpgv groff-base ifupdown iproute2 iptables iputils-ping isc-dhcp-client isc-dhcp-common kmod less libapt-inst1.5 libapt-pkg4.12 libboost-iostreams1.55.0 libcap-ng0 libcgmanager0 libdbus-1-3 libdns-export100 libestr0 libexpat1 libffi6 libglib2.0-0 libgmp10 libgnutls-deb0-28 libgnutls-openssl27 libhogweed2 libicu52 libidn11 libirs-export91 libisc-export95 libisccfg-export90 libjson-c2 liblogging-stdlog0 liblognorm1 libmnl0 libnetfilter-acct1 libnettle4 libnewt0.52 libnfnetlink0 libnih-dbus1 libnih1 libp11-kit0 libpam-systemd libpipeline1 libpopt0 libpsl0 libreadline6 libsigc++-2.0-0c2a libssl1.0.0 libstdc++6 libtasn1-6 libusb-0.1-4 libxtables10 logrotate man-db manpages nano net-tools netbase netcat-traditional nfacct readline-common rsyslog systemd-shim tasksel tasksel-data traceroute vim-common vim-tiny wget whiptail 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. 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 haven't tested the upgrade scenario. Christian [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 -- 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/54587669.4000...@iwakd.de
Bug#746578: libpam-systemd to flip dependencies - proposal
On Sat, 1 Nov 2014 18:55:32 + Ian Jackson ijack...@chiark.greenend.org.uk wrote: 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'. Here, you give the simplified dependency without the version constraint, while below you give the full Depends with version constraint. Please choose one or the other and use it consistently. 2. The effect of this is that installing certain leaf packages which depend 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. Nit: s/certain leaf//; the packages depending on libpam-systemd are not actually leaf packages, and in fact various other packages depend on them. 3. Swappping the order of these dependencies would avoid that and has no harmful effect. I would suggest expanding on what no harmful effect means here: 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. Stating that explicitly in the rationale, to set expectations, seems preferable to a vague no harmful effect that does not fully make sense without reading the full history in the bug. TC decisions should be self-contained. Decision (Constitution 6.1(4)): 4. 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 I think this decision needs to explicitly state that it does not require any particular version numbers in the versioned dependencies, only the specific order. In particular, if libpam-systemd needs to increase its versioned dependency on systemd-shim, or if it ever needs to add a versioned dependency on systemd-sysv, that change should not violate this TC decision. Release (Constitution 6.1(5)): 5. We request that the Release Team allow this change to into jessie. (This request should be conveyed to the Release Team, after the change is in unstable, by filing an unblock request in the usual way.) Is this point necessary? The freeze has not yet occurred, and I don't see any obvious reason why the TC needs to explicitly direct the release team here. - 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/20141102054832.GA1167@thin
Bug#746578: libpam-systemd to flip dependencies - proposal
On Sat, 01 Nov 2014 12:26:14 -0700 Russ Allbery r...@debian.org wrote: So, this is also the last call for anyone to explain what harmful effect this could have if they think it would have a harmful effect. My understanding is that all of the possible harmful effects have been fixed by various other changes. systemd-shim 8-4 and newer no longer seem likely to produce harmful effects, given that systemd-shim now depends on systemd rather than shipping its own D-Bus policy, and that systemd-shim itself pointedly does not launch on systemd systems. Neither of those two properties seems likely to change or break. systemd-shim does depend on cgmanager, which seems more prone to breakage, and in fact has a handful of open bugs on it. cgmanager has in the past broken on non-systemd systems. I personally would like to see a resolution of 755977 to deal with that. 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. - 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/20141102055908.GA1250@thin
Bug#746578: libpam-systemd to flip dependencies - proposal
On Sat, 1 Nov 2014 22:59:09 -0700 Josh Triplett j...@joshtriplett.org wrote: On Sat, 01 Nov 2014 12:26:14 -0700 Russ Allbery r...@debian.org wrote: So, this is also the last call for anyone to explain what harmful effect this could have if they think it would have a harmful effect. My understanding is that all of the possible harmful effects have been fixed by various other changes. systemd-shim 8-4 and newer no longer seem likely to produce harmful effects, given that systemd-shim now depends on systemd rather than shipping its own D-Bus policy, and that systemd-shim itself pointedly does not launch on systemd systems. Neither of those two properties seems likely to change or break. systemd-shim does depend on cgmanager, which seems more prone to breakage, and in fact has a handful of open bugs on it. cgmanager has in the past broken on non-systemd systems. I personally would like to see a resolution of 755977 to deal with that. Important typo here: I meant cgmanager has in the past broken systemd systems. I had bugs like 761389 in mind there. Hence 755977. 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. - 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/20141102135634.GA1220@thin
Bug#746578: libpam-systemd to flip dependencies - proposal
Thanks for your review. I appreciate the attention to detail. Josh Triplett writes (Bug#746578: libpam-systemd to flip dependencies - proposal): Here, you give the simplified dependency without the version constraint, while below you give the full Depends with version constraint. Please choose one or the other and use it consistently. I don't mind changing this. On Sat, 1 Nov 2014 18:55:32 + Ian Jackson ijack...@chiark.greenend.org.uk wrote: 2. The effect of this is that installing certain leaf packages which depend 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. Nit: s/certain leaf//; the packages depending on libpam-systemd are not actually leaf packages, and in fact various other packages depend on them. I will change this to some packages which depend (directly or indirectly) on libpam-systemd. 3. Swappping the order of these dependencies would avoid that and has no harmful effect. I would suggest expanding on what no harmful effect means here: 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. Stating that explicitly in the rationale, to set expectations, seems preferable to a vague no harmful effect that does not fully make sense without reading the full history in the bug. TC decisions should be self-contained. Thanks for that helpful text, which I have adopted. 4. 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 I think this decision needs to explicitly state that it does not require any particular version numbers in the versioned dependencies, only the specific order. In particular, if libpam-systemd needs to increase its versioned dependency on systemd-shim, or if it ever needs to add a versioned dependency on systemd-sysv, that change should not violate this TC decision. I am happy to clarify this. I have added: 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)): 5. We request that the Release Team allow this change to into jessie. (This request should be conveyed to the Release Team, after the change is in unstable, by filing an unblock request in the usual way.) Is this point necessary? The freeze has not yet occurred, and I don't see any obvious reason why the TC needs to explicitly direct the release team here. Unless my understanding of the release schedule is confused, I think that a change to the systemd source package, uploaded now, would not make it into jessie without a freeze exception. But I'm happy to make this contingent. How about: 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. 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/21590.15521.463663.833...@chiark.greenend.org.uk
Bug#746578: libpam-systemd to flip dependencies - proposal
Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - proposal): Here is my draft, just committed to git. I'm open to suggestions for changes. If we can't agree on the rationale I guess we could leave it out. Josh Triplette produced a helpful detailed review. Here is the revised draft. 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/21590.15745.823521.394...@chiark.greenend.org.uk
Bug#746578: libpam-systemd to flip dependencies - proposal
On Sun, 2 Nov 2014 14:19:45 + Ian Jackson ijack...@chiark.greenend.org.uk wrote: Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - proposal): Here is my draft, just committed to git. I'm open to suggestions for changes. If we can't agree on the rationale I guess we could leave it out. Josh Triplette produced a helpful detailed review. Here is the revised draft. s/Triplette/Triplett/ :) And thank you for the update. One minor (but semantically significant) issue below, caused by a typo in my original suggestion. 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. s/intentionally do not have systemd/intentionally do not have systemd-sysv/ - Josh Triplett 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/20141102171044.GA6632@thin
Bug#746578: libpam-systemd to flip dependencies - proposal
Josh Triplett writes (Bug#746578: libpam-systemd to flip dependencies - proposal): On Sun, 2 Nov 2014 14:19:45 + Ian Jackson ijack...@chiark.greenend.org.uk wrote: Josh Triplette produced a helpful detailed review. Here is the revised draft. s/Triplette/Triplett/ :) Glerk. Sorry! I got your name right _most_ of the times... One minor (but semantically significant) issue below, caused by a typo in my original suggestion. ... 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. s/intentionally do not have systemd/intentionally do not have systemd-sysv/ Fixed in git. I hereby make that change to my formal proposal. Thanks, 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/21590.30193.479905.710...@chiark.greenend.org.uk
Bug#746578: libpam-systemd to flip dependencies - proposal
Here is my draft, just committed to git. I'm open to suggestions for changes. If we can't agree on the rationale I guess we could leave it out. 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'. 2. The effect of this is that installing certain leaf packages which depend 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. Decision (Constitution 6.1(4)): 4. 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 Release (Constitution 6.1(5)): 5. We request that the Release Team allow this change to into jessie. (This request 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/21589.11428.723774.778...@chiark.greenend.org.uk
Bug#746578: libpam-systemd to flip dependencies - proposal
Ian Jackson ijack...@chiark.greenend.org.uk writes: 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'. 2. The effect of this is that installing certain leaf packages which depend 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. Decision (Constitution 6.1(4)): 4. 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 Release (Constitution 6.1(5)): 5. We request that the Release Team allow this change to into jessie. (This request should be conveyed to the Release Team, after the change is in unstable, by filing an unblock request in the usual way.) This looks fine to me. So, this is also the last call for anyone to explain what harmful effect this could have if they think it would have a harmful effect. My understanding is that all of the possible harmful effects have been fixed by various other changes. -- 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/877fzesox5@hope.eyrie.org