Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Thu, Feb 06, 2014 at 10:20:02AM +0100, Didier 'OdyX' Raboud wrote:
> L really reads to me like a way to enforce support for all init systems
> alike (thereby ensuring that the default init gets the same [bad]
> support) on maintainers and I feel it's too coercitive.
I don't interpret L as meaning that everything must support "all" init
systems, certainly not "alike" (indeed the text of that option is
explicit that it isn't necessarily alike). Rather, I interpret it as
saying that software-outside-init must be flexible enough to cope with
that possibility, and degrade sensibly to a lowest common subset of init
system features (IOW in practice, needs to keep working if sysvinit is
pid 1). Actual support for things beyond that minimum will require
people who care about various init systems to step up and implement it.
> * L would enforce that any software can run on all inits (failure to
> work on one is equivalent to requiring any of the other ones, henc
> failing the requirement of L)
That's not how I interpret it. "A specific init system" is in the
singular. I'm not worried that we'll end up with cases where
software-outside-init somehow manages to work with two init systems but
not the others; working with more than one indicates the basic
flexibility that I want to see, and the rest is up to developers who
care about init systems.
> "All but specific packages are expected to work with the default
> init system. However, where feasible, packages should interoperate
> with all init systems; maintainers are encouraged to accept
> technically sound patches to enable interoperation, even if it
> results in degraded operation while running under the init system
> the patch enables interoperation with."
Doesn't that just move the question to what the "specific packages" are,
the scope of which is the core of the difference between T and L anyway?
Colin Watson [firstname.lastname@example.org]