Bug#727708: loose ends for init system decision
On Mon, Dec 30, 2013 at 1:47 PM, Russ Allbery wrote:
>
> 4. Conclusions
>
> I previously argued that much of the benefit of a new init system comes
> from when we can stop maintaining init scripts. I still believe that, but
> after thinking more about the cultural and project issues at stake here,
> as well as the immediate needs for a clean upgrade path, I ended up at
> more of a compromise position than I expected.
>
> I believe Debian should take this path forward:
>
> 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.
>
> 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.
>
> 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).
>
> 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. However, for as long as Debian has accepted
> non-Linux ports using a different init system, package maintainers
> should continue to ship init scripts if they work and should apply
> patches and other reasonable fixes from porters for those init scripts.
> In other words, this should be treated the same as merging patches for
> the Hurd to remove hard-coded constant assumptions: if the change is
> reasonable and doesn't break Linux ports (and this should be fairly
> easy to handle for nearly all cases with init scripts), the package
> maintainer should merge it.
>
> 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. If we select
> systemd, package maintainers should still be willing to merge
> contributed upstart configuration, with the understanding that they
> can't test it and any support is on a best-effort basis only.
> Similarly, if we select upstart, package maintainers should be willing
> to merge systemd unit files and to enable upstream systemd support
> where requested and where it doesn't interfere with the operation of
> the daemon under upstart, with the understanding that the package
> maintainer is not committing to testing or directly supporting this
> configuration.
>
> 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.
>
> 7. After jessie, functionality between systems running the primary Linux
> init system and other init systems (including non-Linux ports) should
> be allowed to drift. In other words, there will be cases where
> features will only be available with the primary init system. Possible
> examples include security hardening, socket activation, automatic
> daemon restarts, and so forth. Packagers are under no obligation to
> port those features to other init systems, but should welcome and merge
> patches that do so. After jessie, packagers will no longer be required
> to preserve daemon configuration when the init system is switched, so
> use of such facilities as modification of upstart configuration files
> or systemd overrides may be used.
>
> We should revisit this decision again after the jessie release in case the
> situation has substantially changed.
Doesn't a TC mandate on the default init system in some sense violate
Debian's spirit of meritocracy? May I suggest something like the
following (this isn't meant to be definitive) as a more meritocratic
approach:
1. The TC encourages a team (probably debian-boot) to provide a
package (similar to tasksel), let's call it initsel, that prompts
users during an expert install (and dpkg-reconfigure) time to make an
init system selection (with sysvinit as the default to begin with)
2. The TC recommends approving jessie release goals to support all of
the viable init systems (concurrently maintaining full support for
sysvinit).
3. The TC recommends that initsel support selection among any of the
init systems that are sufficiently capable on the user's current
architecture.
4. When the init systems sufficiently support all of the planned
release architectures, which would include kfreebsd-* (at least for
now) and possible hurd if it does become an officially supported arch,
the TC recommends that the team supporting initsel evaluate changing
the default to their best choice among all of those init systems that
do support all of the release architectures.
5. At some future point deprecate sysvinit and any of the other init
systems that are clearly not worth continuing, and encourage
maintainers to remove support for those.
Doing something like this, the best init system can win based truly on
merit (if/when the work gets done), rather than as a fuzzy upfront
judgement call.
Best wishes,
Mike
Reply to: