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. "Ian's": ======== 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 system) 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. "my's": ======= 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 functional. 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". Lucas
Attachment:
signature.asc
Description: Digital signature