On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson < ijack...@chiark.greenend.org.uk> wrote:
> Ian Jackson writes ("Re: Bug#727708: init system discussion status"): > > I have written a draft resolution from my own point of view and > > checked it into the tech-ctte git repo. Perhaps some of it is useful. > > Ansgar commented a bit on it on IRC. I guess I should post it. > > Here's my draft. > > > Those who prefer systemd will want to s/upstart/systemd/ and vice > versa, obviously. Aside from that: > > 0,3,4,5,8,10 are probably not very controversial (mutatis mutandi > for those who prefer systemd). > > 2 (non-Linux ports) needs attention in the systemd case. > > 6 will not be controversial (mutatis mutandi) except: > > 6C (and the consequential paragraphs) may be quite controversial even > amongst those who prefer upstart. This needs further discussion. > > 7 probably needs to deal with systemd too in any case; the > corresponding feature is "guess main pid" I think. > > 9's usefulness was doubted by Russ, but I hope the substance at least > is uncontroversial. > > 11 is probably going to be thought inappropriate but I wanted to at > least float it. > > Of course some of you may want to take a completely different > approach, perhaps specifying things in much less detail. > > For the "punt it to a GR" option, I don't think we should specify this > level of detail about compatibility, policy, accepting patches etc. > We should provide at least four draft ballot options (upstart, > systemd, sysvinit, openrc) and request that the DPL propose the GR as > the TC is too unweildy for handling amendments for something > time-critical like this. The ballot options we suggest should all > state that sysvinit is still mandatory to support in jessie. > > Thanks, > Ian. > > | 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 will be upstart. > | > | 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. > | > | [ 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. > | > Should it not be added that raise(SIGSTOP) should only be used with a command line option (like --debian-Z) to ensure that the daemon does not hang on sysv or systemd? Cheers, Cameron Norman