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.
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.