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