-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
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. ]
projects / debian-ctte.git / commitdiff