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

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
that mail.]

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

> 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
> important.
> 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
  two reasons.
- 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
> this.

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
cooperative development?

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

Reply to: