Bug#727708: init system discussion status
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.
|
| (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. ]
Reply to: