Bug#727708: Processed: block 726763 with 727708
[I'm going to avoid responding to the points of this mail that Russ
already did in his response, in favor of just agreeing entirely with
Steve Langasek wrote:
> On Sat, Feb 01, 2014 at 12:34:19PM -0800, Russ Allbery wrote:
> > Wouldn't it be more reasonable to assume that the proper solution may
> > depend on the TC decision and the corresponding fallout to package naming
> > and structure, and hence it's reasonable to wait for the decision and
> > subsequent fallout (particularly since that's close) rather than doing
> > work now that may not apply to the final state of the world?
> I don't think it's reasonable to leave testing and unstable users of our
> default desktop environment without working suspend and resume for more than
> a month (systemd-shim was accepted into unstable on Dec 28, and this was
> mentioned on the bug) when a one-line change would fix the problem.
As you already noted, your proposed solution had not been posted to the
bug, and your statement that systemd-shim was not ready had been; thus,
it doesn't seem particularly unreasonable for the maintainers to assume
it wasn't yet a viable alternative. Furthermore, even the "one-line
change" you're proposing needs some further discussion to evaluate it,
and it has not yet had that discussion. Based on both of those points,
I don't think it's at all reasonable to use 726763 as evidence that
maintainers are not interested in supporting alternate init systems. I
still think it quite likely that the majority of maintainers will take
reasonable steps to incorporate proposed patches to support alternate
> And that fix would not cease to be correct if the TC decided that only
> systemd should be supported for jessie, it would just cease to be
> I don't see anything in the options the TC
> is considering, or in the broader discussion generally, which would impact
> the maintainers' course of action here.
> In other words: I think the technically correct thing here is obvious and
> simple and invariant with respect to any decision the TC is going to make;
> so the only way it makes sense to me that resolving the bug depends on the
> TC decision is if the maintainers don't intend to do the correct, obvious,
> simple thing unless the TC /requires/ them to do so.
I think it's entirely possible that your proposal is not the "correct,
obvious, simple thing" you see it as; it's not even the "correct,
obvious, simple thing" for everyone who has been neck-deep in the
entirety of this discussion, let alone for those who haven't been.
I can also see several reasonable ways in which the appropriate change
to this or any other involved package might differ based on the outcome
of the TC decision. I don't think it's reasonable, given a very large
solution space, to give preference to proposals based on their ability
to keep their distance from 727708, rather than evalating all proposed
solutions equally even if some might get embroiled in 727708. For that
reason as well as just to limit complexity, I also think it's perfectly
reasonable for a maintainer to wait for an outcome to 727708 before even
enumerating the solution space.
A brief, decidedly non-exhaustive look at the (potentially overlapping)
solution space many packages could end up facing:
- Add a dependency on "systemd-as-pid-1 (however we end up representing
that) | systemd-shim (or similar substitute as applicable)". That
would be appropriate if systemd becomes the default, or if the package
provides degraded functionality under the alternative system was
- Add a dependency in the reverse order, for the reverse of the above
- Add a "Recommends: systemd-as-pid-1". (Would work better if
alternatives to systemd conflicted with it, so that you end up with
systemd-as-pid-1 unless you have an alternative already installed or
you intentionally ignore the recommends.)
- Request a co-maintainer to keep an alternative tested and working.
- Go up a level in the dependency stack and add an alternative
dependency: "package-requiring-systemd |
forked-package-maintained-by-someone-else", or an equivalent involving
virtual packages, if a package requires invasive changes the
maintainer doesn't wish to merge.
- In the case of a daemon package, split out a foo-bin and foo package,
allowing for a foo-otherinit package depending on foo-bin. Often
convenient for other reasons, as well.
- Change the maintainer to Debian QA Group (to further abuse Russ's
metaphor, "shoot the hostage").
> And if we already have examples of this before we've even changed the
> default init, then I don't think we should pass any resolution that
> says we welcome multiple init systems while at the same time leaving
> the door open for maintainers to reject even such simple changes as
Given that 726763 does not actually qualify as evidence for your
conclusion here, do you have any actual evidence that maintainers will
behave as you fear, rather than that maintainers are capable of ongoing
I'd also suggest in general that anyone looking to produce a non-trivial
patch for a package might want to talk to the maintainer of that package
to see what form of patch they would accept, which would be a far more
effective means of avoiding wasted development effort.
- Josh Triplett