Lucas Nussbaum writes ("Re: Alternative proposal: support for alternative init
systems is desirable but not mandatory"):
> I don't think that it's useful to change this rule to:
> packages MUST work with at least one alternative init system as PID 1
> or
> packages MUST work with some alternative init systems as PID 1
Your Q&A is helpful but I don't think it belongs in the GR text.
I agree with Jonas's objection on this specific question, even after
reading your mail here.
> So I think that we are down to two solutions that really preserve the
> 'freedom'
> to choose an init system:
I mostly agree with your technical analysis.
> 2) packages MUST work with a specific interface, which is basic enough to
> enable all alternative init systems to support it. The most natural such
> interface is currently sysvinit: if a package works with sysvinit as PID 1, it
> currently also works with upstart, openrc, etc.
The wording in my resolution comes from the TC discussion and
specifies `at least one' or `some alternative'. To represent that as
`all' is IMO misleading.
One important difference between `all' and `at least one' is this:
suppose there is some init system that does not support the common
interface you suppose in your point (2). Saying `all' suggests that
it is somehow the fault of the packages which deal with the common
interface. This point was raised in the TC discussion.
Saying `all' gives the impression that every package must do work for
each init system. That is why my proposal's wording simply says that
packages are forbidden from requiring `a specific' init system.
> Ian, do you agree that this correctly captures your opinion and the set of
> available options?
There are various ways of systematising the questions in this area.
Your analysis is, I think, helpful, but I don't want to privilege it.
The text in my proposal is taken directly from the TC discussion where
its details were extensively debated.
> What do you think of withdrawing both your and my proposal, and
> designing a ballot based on the above set of options (re-adding all
> the small details that I left out for clarity, e.g. what amount of
> degraded operation is acceptable, what are the exceptions, etc)?
So I'm afraid I don't want to do that.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21571.48226.818607.308...@chiark.greenend.org.uk
