Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

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.