[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

On 28/10/13 at 18:21 -0700, Russ Allbery wrote:
> Wouter Verhelst <wouter@master.debian.org> writes:
> > Also, since all alternative init implementations under consideration do
> > support sysv-style init scripts, I think that whatever init system we
> > (well, you, the TC) end up choosing, the requirement in policy should be
> > that a package should ship either some init configuration for the
> > default init system, or a sysv-style init script. In fact, I think we
> > should continue to encourage the latter, in cases where it does make
> > sense (e.g., when a given daemon doesn't have any init system specific
> > features that could be enabled), since that will help our non-Linux
> > ports without significantly impacting performance of the new init
> > system.
> Well, I've said this before, but I think it's worth reiterating.  Either
> upstart or systemd configurations are *radically better* than init scripts
> on basically every axis.  They're more robust, more maintainable, easier
> for the local administrator to fix and revise, better on package upgrades,
> support new capabilities, etc.
> I believe that much of the benefit for adopting a new init system is
> dropping init scripts and using a much better configuration language.  If
> we're not going to take advantage of that benefit, it calls into question
> whether we should change init systems at all.

Note that there are two options that could be explored, to remove the
need to maintain init scripts:
- generating sysvinit scripts from systemd service files or upstart job
  files at build time (this was explored, for systemd service files,
  during a GSoC project in 2012, without much success)
- having a .service/job files runtime interpreter (that sounds quite

Even if it cannot be used for all services, using such as interpreter
could maybe provide an easy support path for sysvinit on non-linux
platforms for a large number of "simple" services.

There's a subthread about that starting at
Helmut Grohne (Cced) did most of the work on analyzing those possibilities.


Reply to: