Re: Why focus on systemd?
On 11/24/2014 02:14 AM, Didier 'OdyX' Raboud wrote:
Le dimanche, 23 novembre 2014, 18.09:58 Marty a écrit :
Did I miss something?
Yes.
Option 1: init policy stands *won by default* [1]
Option 2: change init policy *LOST*
Option 3: ask nicely to follow init policy *lost*
Option 4: policy stands, no statement needed *WON*
Option 5: null option, further discussion *won by default*
[1] depending on bug status of package dependence on PID 1, so maybe
this is the real issue
Iff you're using the same option numbers as those on the ballot, that's
a totally wrong reading of the GR results, IMHO.
Option 4 won all pairwise duels against all other options, and as such,
is the winning option. All other options besides 5 (FD) won their
pairwise duels against FD. Saying that "Option 1 (…) won by default" is
factually wrong. It's summary was not "init policy stands" either.
OdyX
This is only my interpretation as an armchair observer, also in the US
called "Monday morning quarterback."
It was a policy vote. The only "results" that matter are their effect
on Debian Policy, right? The rest is academic.
The vote invoked a clause in the TC init decision to allow modifying or
overturning the policy set by the TC init decision, in anticipation of
confusion or disagreement over its effect.
Option 1 only restates or clarifies the existing init policy, 9.11,
which is designed to preserve init system choices and prevent the kind
of problems posed by systemd:
"However, any package integrating with other init systems must also be
backwards-compatible with sysvinit ..."
So that leaves only the PID 1 question (hence my footnote). Note,
however, that there is no reasonable way to claim that any package that
only works with systemd as PID 1 could be regarded as "backwards
compatible with sysvinit," so Option 1 was a non-controversial
interpretation of Debian Policy (as I read the -vote discussion).
The only (or main) issue was only that it should be put to a vote,
or at least put to a vote in this way, hence Option 4 was included.
Option 4 states that the policy is fine and no restatement about PID 1
is needed. It does not say Option 1 is the wrong interpretation of
policy. Only Option 2 overturns policy, by negating Option 1. Option 4
indirectly negates Option 2 and does not say anything about any other
options.
Option 1 therefore wins by default, especially if the (apparent)
consensus about init coupling being a bug is affirmed in practice.
The project seems to be saying that the issue should be resolved case
by case and not be subject to a blanket rule, which seems reasonable
to me. The vote also explains why the GR was rejected the first time
around.
Reply to: