From: Ian Jackson Date: Thu, 2 Jan 2014 15:36:20 +0000 (+0000) Subject: 727708: more work on my draft resolution X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=a0d80d12d0de6cab4e92953360b3086129bcaaad;p=debian-ctte.git 727708: more work on my draft resolution --- diff --git a/727708_initsystem/draft-resolution-iwj.txt b/727708_initsystem/draft-resolution-iwj.txt index cc827f5..72a3a6e 100644 --- a/727708_initsystem/draft-resolution-iwj.txt +++ b/727708_initsystem/draft-resolution-iwj.txt @@ -1,118 +1,152 @@ -1. The default init(1) in jessie should be upstart. +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. -2. General requirements for new init system support patches +Choice of init system: + +1. The default init(1) in jessie will be upstart. - (We observe and advise:) +2. Architectures which do not currently support upstart should try to + port it. If this is not achieved in time, those architectures may + continue to use sysvinit. [ 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. - Patches to update a package to support a new init system should: - (a) use a non-forking startup protocol; - (b) not introduce additional build-dependencies; - (c) not introduce additional runtime dependencies; - (d) not introduce substantial amounts of new code into - the daemon (code to connect to an AF_UNIX socket and send - a message counts as substantial; code to write to an - already-open fd, or raise a signal, does not); - (e) not introduce embedded copies of library code; - (f) if changes are necessary to the core daemon code, make those - changes acceptable to the daemon's upstream if possible; - (g) use the startup protocol chosen by the upstream maintainer - or failing that the Debian maintainer, subject to (a)..(f); - (h) not introduce significant amounts of hard-coded boilerplate - in package maintainer scripts or rules files; - (i) use facilities documented in the reference manuals for the - init system in question (as found in sid); + [ 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. ] - Such patches might well (and probably often will): - (m) introduce new code in the main body of the daemon to support - non-forking startup, socket activation or readiness signalling, - including in particular the upstart raise(SIGSTOP) protocol; - (n) introduce new command-line options to request the new - startup mode(s); - (o) honour additional environment variables to request the - new startup mode(s); - (p) introduce new code to remove such environment variables - from the environment of the daemon's descendants; - (q) introduce new debhelper calls (or handwritten rules code, - if that's how the rules file is structured already) to - place the relevant files in the binary package and - perhaps relevant runes in the maintainer scripts. +Policy is not ready, so hold off on updating all packages: - (The TC directs the policy editors:) +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. ] - Policy should be amended to reflect the advice given in 2(a)..(e) - above. ((f)..(i) are thought obvious or out of scope for policy.) +Support requirements for packages: -2. Maintainer receptiveness to patches +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. - (We observe and advise:) + [ 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 maintainer for a daemon package should apply any - submitted reasonable patches to provide native upstart or systemd - support (or to convert existing upstart or systemd support to a - non-forking startup protocol). + The Debian Project Leader and/or applicable Delegates should give + effect to this part of our decision. ] - This is provided that these patches meet the criteria (a)..(i) - above. That such patches have the features described in (m)..(q) - above should not be regarded as blockers for acceptance. +6. [ Maintainers should accept reasonable patches for native upstart, + systemd and openrc support. - Failure to deal with patches in a constructive way is likely to - lead to a decision by the TC to overrule the maintainer. + 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. -3. Requirement to support upstart + 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. - (We decide, pursuant to the referral of the init system decision to - us, that:) + 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 lsb-base; or + (iii) Introduces other than trivial new code into the daemon. - Packages should provide native upstart jobs where relevant. + 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. - Patches for upstart support should be treated analogous to the way - "release goals" have been treated in the past: so, for example, - they should have a low NMU threshold. + We are aware that at present it is not possible to provide a patch + for systemd's main non-forking daemon startup readiness protocol + which is necessarily reasonable by this definition. If the systemd + community in Debian wants the widest adoption in the project, this + should be addressed by changes to the systemd package. - Lack of native upstart support is not a release-critical bug - for jessie. + 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. ] -4. Cross-init system compatibility +Detailed policy specifications: - (We observe and advise:) +7. No package in Debian may 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. - Debian contributors are encouraged to explore and develop ways in - which a package can provide support for 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. +8. Policy rules for support for upstart and systemd must: -4. Requirement to support other systems + (a) Specify the use of a non-forking startup protocol. - (We decide, pursuant to the referral of the init system decision to - us, that:) + (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: - At least in jessie, unless a satisfactory approach to (3) is - developed and deployed, packages must continue to provide sysvinit - scripts. + (a) If changes are necessary to the core daemon code, make those + changes acceptable to the daemon's upstream if possible. - After jessie, the policy editors may drop this requirement; either - entirely, or in favour of a requirement to provide at least one of - sysvinit or systemd integration. + (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. -5. Policy for new init systems + (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. - (We advise:) + (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). ] - The current Debian policy for upstart, in the policy manual, could - do with some improvement and enhancement. +Cross-init-system compatibility: - The current Debian policy for systemd needs to be finished and - agreed, and then incorporated in the policy manual. +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: - We encourage the maintainers of upstart and systemd, and others, to - submit relevant policy enhancements. - -6. Replacement of existing functionality - - (We observe and advise:) - - Sometimes it is proposed that a package should take over some +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 @@ -130,8 +164,4 @@ 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. - -7. Startup protocol improvement - - We encourage upstart and systemd + the existing interface, or via a wholly new interface. ]