[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On 19/10/14 at 14:28 +0100, Ian Jackson wrote:
> > 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.

I don't follow you here.

Your main goal is to preserve the ability to switch between init

Your proposal, even modified with "one specific init system", doesn't
fully preserve that ability: as pointed out by David Weinehall in
<20141019141318.GC8499@hirohito.acc.umu.se>, one could introduce another
init system that shares systemd's interfaces, thus enabling packages to
statisfy your condition (they would require systemd and one alternative:
that systemd-compatible init system) while breaking the ability to
switch to sysvinit or upstart.

Requiring support for sysvinit sounds exactly like what you really want,
since users could then switch to any sysvinit-compatible init system.
Why not say so explicitely?



Attachment: signature.asc
Description: Digital signature

Reply to: