[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#746578: Revised call for votes (was libpam-systemd to flip dependencies - proposal)

I vote Y, FD on the following.

Ian Jackson <ijackson@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 (>= 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-sysv 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.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Attachment: pgpfWuLB71imx.pgp
Description: PGP signature

Reply to: