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

Re: Alternative proposal: support for alternative init systems is desirable but not mandatory

On 17/10/14 at 09:44 +0200, Lucas Nussbaum wrote:
> I am therefore bringing forward an alternative proposal, deeply inspired
> from the "Advice: sysvinit compatibility in jessie and multiple init
> support" option of the TC resolution on init system coupling[1], which
> was originally written by Russ Allbery[2] and was then amended by many
> participants to the discussion in February 2014.

It was pointed out that a TL;DR version might be useful. Here is an attempt,
using RFC 2119 MUST/SHOULD/MAY/etc (note that the meaning of SHOULD in RFC 2119
is stronger than a simple advice). I've also simplified the statements, which
of course hides some details and adds some possible loopholes.

Packages MUST NOT require a specific init system to be PID 1.
(exceptions: alternative init systems; special-use packages such as
managers for init systems; cooperating groups of packages intended for
use with specific init systems -- but only if not required by other
software whose main purpose is not the operation of a specific init
But packages MAY provide degraded operation with some init systems.
(normal rules about bugs severity apply, no worse)

Maintainers SHOULD accept technically sound patches to improve
interoperation with various init systems.

Packages SHOULD support the default init system on all architectures for
which they are built. [there are examples of circumstances where this can
be ignored in the proposal]
For jessie, all software currently supporting sysvinit MUST continue
to support sysvinit (exception: there is no technically feasible way to do
so). Degraded operation is acceptable as long as the package is basically

Maintainers SHOULD merge any contributions for support of any init system.
Maintainers SHOULD merge, with high priority, changes to support any init
system which is the default on one of Debian's non-Linux ports.
Maintainers MAY add that support themselves.

Actually, I wonder if both proposals shouldn't be rewritten using RFC 2119 to
make them clearer.

For example, Ian's "software may not require a specific init system to be pid
1" could be abused by introducing a systemd-clone package in the archive, so
that packages require "systemd or one of its clones", which isn't really "a
specific init system". What this proposal means is not very clear if it's not
"software MUST work with all init systems in Debian".


Attachment: signature.asc
Description: Digital signature

Reply to: