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 should delay introducing patches for native support for upstart, systemd or openrc until the relevant Debian Policy is declared, by the Policy editors, to be ready. ] 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), (b) Use facilities documented in the reference manuals for the init system in question (as found in sid). [ This requirement cannot be met until the init system has a suitable reference manual. ] (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. ]