+++ /dev/null
-Rubric:
-
-0. We decide as follows (Constitution 6.1(1),(2)). Text in square
- brackets "[]" is non-binding advice (Constitution 6.1(5)). We
- require the Policy Editors (Constitution 6.1(1)) to make the policy
- changes they think appropriate to give effect to this resolution.
-
-Choice of init system:
-
-1. The default init(1) in jessie for Linux architectures will be
- upstart.
-
-2. The default init(1) in jessie for non-Linux ports will be upstart
- if it has been ported and confirmed by the porters to be working by
- the time of the jessie release. Failing this, the default init(1)
- in jessie for non-Linux ports is left to the discretion of the
- maintainers of that port.
-
- [ However, the Technical Committee requests that, should upstart be
- unavailable on both Hurd and kFreeBSD, the Hurd and kFreeBSD
- porters agree on a single alternative init(1) implementation that
- will be shared by both ports. ]
-
- [ Non-use of upstart should not be a criterion for architecture
- qualification status in jessie. ]
-
-3. At least in jessie, unless a satisfactory compatibility approach is
- developed and deployed (see paragraph 10), packages must continue
- to provide sysvinit scripts. Lack of a sysvinit script (for a
- daemon which contains integration with at least one other init
- system) is an RC bug in jessie.
-
- Likewise, packages must not Depend on or Recommend (directly or
- indirectly) a specific init(1). Violations of this are also an RC
- bug in jessie.
-
- Theses rules do not apply to machinery which itself forms part of
- the implementation of one or more init systems.
-
- [ After jessie, the policy editors may drop this requirement;
- perhaps entirely, or perhaps in favour of a requirement to provide
- at least one of sysvinit or systemd integration. The policy
- editors may wish to refer this decision to us in due course. ]
-
-Policy is not ready, so hold off on updating all packages:
-
-4. [ The current Debian policy for upstart, in the policy manual,
- could do with some improvement and enhancement. The current Debian
- policy for systemd needs to be finished and agreed, and then
- incorporated in the policy manual. We encourage the maintainers of
- upstart and systemd, and others, to submit relevant policy
- enhancements.
-
- Contributors who have not already added native support for upstart,
- systemd, or OpenRC may wish to wait until the relevant Debian
- Policy is declared, by the Policy editors, to be ready. Early
- adopters should be aware that the requirements may change and their
- packages may require updates. ]
-
-Support requirements for packages:
-
-5. Subject to paragraphs 4 and 6 of this resolution, packages should
- provide native upstart jobs where relevant.
-
- Lack of native upstart support is not a release-critical bug for
- jessie.
-
- [ Patches for upstart support should be treated the way "release
- goals" have been treated in the past; so, for example, there should
- be a low NMU threshold for patches meeting suitable criteria.
-
- The Debian Project Leader and/or applicable Delegates should give
- effect to this part of our decision. ]
-
-6. [ Maintainers should accept reasonable patches for native upstart,
- systemd and openrc support.
-
- A. A reasonable patch:
- (i) is proposed after the relevant policy is finalised;
- (ii) complies with that policy;
- (iii) complies with the advice and requirements in this
- resolution; and
- (iv) takes the approaches to integration chosen by upstream,
- or failing that by the Debian maintainer.
-
- B. A patch is not unreasonable just because:
- (i) the package upstream (or the Debian maintainer) does not wish
- to support the relevant init system at all; or
- (ii) they do not wish to support any of the suitable non-forking
- startup protocols offered by that init system.
-
- C. However, a maintainer is entitled to consider a patch unreasonable
- if it:
- (i) Requires additional build-dependencies; or
- (ii) Requires additional runtime dependencies except sysv-rc; or
- (iii) Introduces other than trivial new code into the daemon; or
- (iv) "Abuses" SIGSTOP as done by the upstart "expect stop"
- protocol and as disliked by the systemd community.
-
- Code to write to an already-open fd and close it, or to raise a
- signal, will usually be trivial for these purposes. (This includes
- enabling the new protocol via command-line switches or environment
- variable tests, and removing any small fixed set of associated
- variables from the environment.) Code to connect to an AF_UNIX
- socket and send a message will not usually be considered trivial.
-
- We are aware that at present it is not possible to provide a patch
- for any of systemd's or upstart's main non-forking daemon startup
- readiness protocols which is necessarily reasonable by this
- definition.
-
- Therefore if the upstart and systemd communities in Debian want the
- widest adoption in the project, these problems should be addressed
- by changes to the upstart and systemd package to widen their
- support for different startup protocols. Ideally each init should
- in any case provide support for the main protocols supported by
- their competition.
-
- Failure to apply reasonable patches, including failure to explain
- promptly and constructively why a patch is not reasonable, is
- likely to lead to the maintainer being overruled. ]
-
-Detailed policy specifications:
-
-7. [ No package in Debian should use "expect fork" or "expect daemon"
- in upstart jobs. The corresponding code in upstart may be disabled
- or compiled out on some or all architectures. ]
-
-8. Policy rules for support for init systems must:
-
- (a) Specify the use of a non-forking startup protocol (for
- upstart and systemd),
-
- (c) Require that environment variables and fds involved in the
- daemon startup protocol should not in general be inherited by
- the daemon's descendants.
-
- (d) Forbid the introduction of embedded copies of library code
- (or the use of any embedded copies included by upstream).
-
-9. [ Policy should provide non-binding suggestions to Debian
- contributors who are converting daemons to upstart and/or systemd,
- for example:
-
- (a) If changes are necessary to the core daemon code, make those
- changes acceptable to the daemon's upstream if possible.
-
- (b) It is fine to introduce new code in the main body of the daemon
- to support non-forking startup, socket activation or readiness
- signalling.
-
- (c) Support for upstart is usually best provided with the
- raise(SIGSTOP) non-forking daemon readiness protocol, unless
- and until a better protocol is available.
-
- (d) It is fine to introduce new command-line options to request the
- new startup mode(s), or to honour additional
- init-system-specific environment variables to request the new
- startup mode(s). ]
-
-Cross-init-system compatibility:
-
-10. Debian contributors are encouraged to explore and develop ways in
- which a package can provide support for non-forking startup in
- multiple different init systems without having to have separate
- support for each init system in the source package; and, ideally,
- without having to have separate support for each init system in the
- binary package.
-
-Replacement of existing functionality - process:
-
-11. [ Sometimes it is proposed that a package should take over some
- function currently performed by an existing different package.
-
- In such cases, the consent of the maintainers of the the package
- currently providing the functionality should be sought, or failing
- that, consensus obtained from the project as a whole in the usual
- way.
-
- This discussion should ideally take place before implementation
- work starts on the proposed replacement. If and when the change is
- agreed, it should be accompanied by the appropriate policy changes.
-
- It is not proper for anyone declare an existing program obsolete,
- simply on the grounds that they have planned or implemented a
- replacement (whether as part of an existing codebase or otherwise).
-
- These principles apply regardless of whether the proposed new
- implementation provides the functionality via a reimplementation of
- the existing interface, or via a wholly new interface. ]
projects / debian-ctte.git / commitdiff