Bug#727708: loose ends for init system decision
Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
> 1. Role of Non-Linux Ports in Debian
I agree with most of this.
> 2. Impact of Multiple Init Systems
I don't want to do a blow-by-blow quote/rebuttal of this.
> 3. systemd and upstart As Multiple Systems
..
> I therefore think that, regardless of which init system we pick, we should
> keep in mind the above principle of Debian's deference and reasonable
> accomodation to other people's projects and apply that to systemd and
> upstart as well as to the non-Linux ports. Obviously, this also has the
> same issues mentioned above: Debian contributors can only be expected to
> test on the primary init system, other configurations will tend to bitrot
> without active porter attention, and so forth. But if people want to take
> on the work, that deserves our respect.
Right.
> 4. Conclusions
...
> 1. We should select a new init system for jessie, either systemd or
> upstart. Support for that init system should be release-critical, but
> only in the sense that the daemon works properly under that init
> system. In other words, use of the sysvinit compatibility of either
> init system is acceptable support for jessie.
I agree.
> 2. All packages providing init scripts must continue to support sysvinit
> scripts through the jessie release. Such support will continue to be
> release-critical. This is going to be painful for packages that want
> to do an early conversion, since it means testing two different init
> systems for this release cycle, but I think this is the right thing to
> do regardless for a clean upgrade path and Debian's normal robust
> committment to upgrades. Here it has the additional advantage of
> giving the non-Linux ports some breathing space to strategize.
Yes.
> 3. Related, up through the jessie release, packages must (where possible;
> it's possible there will be cases where this is simply impossible)
> support switching back and forth between the new default init system
> and sysvinit. This means that configurations should not be moved out
> of /etc/default and that startup files for the new init system should
> read the same configuration that the existing sysvinit scripts use (or
> both should be modified compatibly).
Yes.
> 4. Post-jessie, support for sysvinit will no longer be release-critical,
> and package maintainers will no longer be expected to ensure that it
> continues working. [...]
>
> 5. Support for the other init system that was not chosen should be handled
> in the same fashion, should a team choose to pursue it. [...]
I think it is probably premature for us to drop support for the other
system in jessie+1.
But we don't need to make this decision now.
> 6. Debian's non-Linux ports should either use the same init system as
> Debian's Linux ports or agree on an init system that they're both going
> to use. The porting work is going to be hard enough without the ports
> going in different directions on which secondary init system they want
> to use. I prefer to leave it up to the porters to decide which init
> system to choose, but I do think OpenRC would be a strong contender.
Is there some difficulty expected with upstart on hurd ?
> We should revisit this decision again after the jessie release in case the
> situation has substantially changed.
I would be very reluctant to write now that the support for sysvinit,
or the non-default new system, may be dropped in jessie+1. That will
result in premature rot and removal.
It's also possible that some kind of compatibility mechanism will
become available.
I would like to leave this decision to the policy maintainers, with
the expectation that the TC will probably need to decide.
Thanks,
Ian.
Reply to: