From af4a76e02f57b383685923d1fdbe2f7e0bdf10ce Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Thu, 2 Jan 2014 14:19:42 +0000 Subject: [PATCH] 727708: my draft resolution, wip --- 727708_initsystem/draft-resolution-iwj.txt | 137 +++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 727708_initsystem/draft-resolution-iwj.txt diff --git a/727708_initsystem/draft-resolution-iwj.txt b/727708_initsystem/draft-resolution-iwj.txt new file mode 100644 index 0000000..cc827f5 --- /dev/null +++ b/727708_initsystem/draft-resolution-iwj.txt @@ -0,0 +1,137 @@ +1. The default init(1) in jessie should be upstart. + +2. General requirements for new init system support patches + + (We observe and advise:) + + 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); + + 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. + + (The TC directs the policy editors:) + + 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.) + +2. Maintainer receptiveness to patches + + (We observe and advise:) + + 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). + + 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. + + Failure to deal with patches in a constructive way is likely to + lead to a decision by the TC to overrule the maintainer. + +3. Requirement to support upstart + + (We decide, pursuant to the referral of the init system decision to + us, that:) + + Packages should provide native upstart jobs where relevant. + + 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. + + Lack of native upstart support is not a release-critical bug + for jessie. + +4. Cross-init system compatibility + + (We observe and advise:) + + 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. + +4. Requirement to support other systems + + (We decide, pursuant to the referral of the init system decision to + us, that:) + + At least in jessie, unless a satisfactory approach to (3) is + developed and deployed, packages must continue to provide sysvinit + scripts. + + 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. + +5. Policy for new init systems + + (We advise:) + + 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. + +6. Replacement of existing functionality + + (We observe and advise:) + + 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. + +7. Startup protocol improvement + + We encourage upstart and systemd -- 2.39.5