Sorry for yet-another-mail on that (long-lasting) bug, but I feel it's
important; so feel free to dismiss it if it isn't bringing to the
conversation.
Le jeudi, 6 février 2014, 16.27:15 Anthony Towns a écrit :
> Rankings between remaning actual outcomes is:
>
> 4x UL > DL > UT > DT (steve, colin, ian, andi)
> 2x DT > DL > UT > UL (russ, don)
>
> So that's
>
> UL > DL > DT 4:2
> UL > UT > DT 4:2
> DL > UT 6:0
I'm quite puzzled by this (partial) result, generally ranking the L
variants over the T's. I think letting any L variant win would create
quite a precedent on what software is "allowed in Debian". "Software"
doesn't imply "package" and is loosely defined, the same goes for
"degraded operation". Is "KDE" a software, or are all of its independent
parts "softwares"? Would "failure to suspend under OpenRC" be an
acceptable degraded operation of the whole "KDE" or only of its
upower/Solid/whatever component?
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.
On the other hand, T apparently brings in the fear of archive
fragmentation by allowing the various init islands to develop on their
own.
Now, I think there is currently a shared agreement in Debian that
"all Debian packages (unless there's a good reason) should run on
sysvinit + Linux + amd64 , support outside that is best-effort"
Now, I think this "default init" decision's purpose is to change the
above agreement by replacing the "syslinux" in the above sentence by one
of the contenders. Both the T and L riders purposedly don't say anything
about the default init, and I think that's wrong:
* T would permit islands outside of the default init (while I think that
some prefer it because it allows the "default init island" to be
technically sane)
* 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)
The "common agreement" above stood until packages started to depend on
systemd, which in the end, lead to the opening of this bug. I think the
technical committee resolution on this issue should focus on outlining
what the "new deal" should be, without stepping into defining what set
of init systems the software shipped by Debian should or must support:
the resolution should be limited to deciding what the new "default init"
will be. Now, if there are concerns of eventual bad faith from the
maintainers, the resolution could include something outlining the
boundaries of the common agreement such as (which I think is the current
consensus):
"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."
That (or any consensual phrasing along these lines) would completely
replace both the T and L riders and be part of the resolution deciding
which init system will be the default. I think that would vastly help
making the decision largely understandable and consensual, where I'm
afraid that any T or L variant would significantly unplease large sets
of maintainers.
Thanks for considering, cheers,
Didier
Attachment:
signature.asc
Description: This is a digitally signed message part.