Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
Aigars Mahinovs writes ("Re: Alternative proposal: support for alternative init systems is desirable but not mandatory"):
> I am inclined to agree with Lucas here - requirement of 'at least one'
> or 'some alternative' are quite imprecise, especially if multiple
> forks of one init system are present in the archive.
Firstly, I don't think it very likely that this is going to be a
problem in practice.
Secondly, this GR does not bind the policy editors, the release team,
or the technical committee. It does not prevent them from adjusting
the wording of policy, or their interpretation of it, if it becomes
necessary to do so in the light of developments. I have confidence
that all of these teams would give proper effect to the intent behind
any GR.
In combination these two factors mean that, if this GR passes, it is
not going to be defeated by such technicalities. If it passes, it
will take effect through its clear demonstration of the views of the
project's governing members.
Looking at this question the from other end, dealing with this
interpretation problem by trying to clarify the wording to explain
what counts as a single init system, seems very unwise. The GR
process is unsuited to that kind of detailed work.
I don't want to deal with this problem by specifically naming
sysvinit. sysvinit itself might be forked, or it might be that all
our daemon packages end up adopting some common startup framework
whose implementation in the sysvinit package is buggy or defective, or
something.
I think naming any particular init in this GR is not a good idea.
Ian.
Reply to: