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 systems. 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? Thanks, Lucas
Attachment:
signature.asc
Description: Digital signature