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

On init in *Debian*



Technical and other merits of contending init systems have been
discussed here at some length. I think we should focus on another
question, namely, which alternative is best suited to *Debian*, taking
into consideration Debian's developer community structure (many
independent package maintainers, minimalistic policy) and the role of
Debian in relation to other distributions, most importantly Ubuntu.

Init system foo might be technically fabulous, but if maintaining foo
in Debian requires frequent simultaneous changes to many packages then
foo might not be well suited to Debian.

By "alternatives" I mean alternative sets of sets of supported init systems:
* sysvinit for all kernels
* Upstart for Linux; sysvinit for others
* systemd for Linux; sysvinit for others
* sysvinit and optionally Upstart for Linux; sysvinit for others
* sysvinit and optionally Upstart and optionally systemd for Linux,
sysvinit and optionally systemd for others
etc., etc.,

The proposal to drop support for kernels other than Linux has already
been adequately aired.  For the sake of focus I'd like to make the
assumption in this thread that support for alternative kernels and
architectures will not be dropped on account of the choice of init
system alternative.

Putting the question another way: is it most compatible with Debian's
structure and consistent with its traditions to continue supporting
sysvinit universally (enforced by policy) and to leave it up to
maintainers, helped by others, to support other init systems alongside
sysvinit?  Then if things happen as they have in the past, Upstart
enthusiasts will open bug reports requesting the inclusion of Upstart
job configuration files; systemd enthusiasts will open bug reports
requesting the inclusion of systemd service files, and so on.

Or do you see some other approach as more compatible and consistent?
-- 
Thomas Hood


Reply to: