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 +0000 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
