From a11ae3f81e6f569220fd1d59d4501552ad0ffc24 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Thu, 30 Jan 2014 14:10:56 +0000 Subject: [PATCH] 727708: replace my draft with Bdale's --- 727708_initsystem/draft-resolution-iwj.txt | 190 --------------------- 727708_initsystem/draft-resolution.txt | 12 ++ 2 files changed, 12 insertions(+), 190 deletions(-) delete mode 100644 727708_initsystem/draft-resolution-iwj.txt create mode 100644 727708_initsystem/draft-resolution.txt diff --git a/727708_initsystem/draft-resolution-iwj.txt b/727708_initsystem/draft-resolution-iwj.txt deleted file mode 100644 index 64525ad..0000000 --- a/727708_initsystem/draft-resolution-iwj.txt +++ /dev/null @@ -1,190 +0,0 @@ -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. ] diff --git a/727708_initsystem/draft-resolution.txt b/727708_initsystem/draft-resolution.txt new file mode 100644 index 0000000..3dbdace --- /dev/null +++ b/727708_initsystem/draft-resolution.txt @@ -0,0 +1,12 @@ + The default init system for Linux architectures in jessie should be + + 1. systemd + + 2. upstart + + 3. openrc + + 4. sysvinit (no change) + + 5. requires further discussion. + -- 2.39.5