Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
> 1. Role of Non-Linux Ports in DebianI 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
