Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > 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. Thank you very much for writing this. (And, in general, thank you for often taking the initiative in producing drafts. It's something that I find difficult, and I really appreciate your work on it.) > 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. That sounds right to me too. > | 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. ] The thrust of this seems right, but I dislike telling people what to do. Can we recast this in a way that avoids that problem? Maybe something like: 1. The default init(1) in jessie for linux-any architectures will be upstart/systemd. 2. The default init(1) in jessie for non-Linux ports will be upstart/systemd if that init system has been ported and confirmed by the porters to be working by the time of the jessie release. Failing this, the default init(1) in jessie for non-Linux ports is left to the discretion of the maintainers of that port. [ However, the Technical Committee requests that, should upstart/systemd not be available for either Hurd or kFreeBSD ports, the Hurd and kFreeBSD porters agree on a single alternative init(1) implementation that will be shared by both ports. ] I'm not sure the point of the bracketed text in yours and whether I've addressed it. Another issue, which I did not address here but which we should probably say something about, is that the init process 1 implementation and the system used to run daemon configuration and startup jobs is separable, and in fact is separated in OpenRC. We should be clear about what we're talking about, particularly when it comes to non-Linux ports. > | 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. This needs the same exception as is currently in Policy 9.11, namely: An exception to this rule is scripts or jobs provided by the init implementation itself; such jobs may be required for an implementation-specific equivalent of the /etc/rcS.d/ scripts and may not have a one-to-one correspondence with the init scripts. > | [ 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. ] This seems okay, although I have a minor preference to just omit this part, since I think it casts Policy in a somewhat weird role and I'm also worried about resources for the Policy process in making that sort of decision. (I'm committing to work on Policy for upstart and systemd support for this specific decision, but can't commit jessie+1 resources.) That's why I was proposing having the TC make the decision now about whether we drop compatibility with sysvinit in jessie+1. If we don't make it, someone else needs to make it, and I'm not sure who that body would be. One possibilty is to explicitly say that we'll make it ourselves after the jessie release. > | 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. ] "Should delay" is a bit strong given that we have many packages in the archive that already provide native support for upstart, and several (including ones maintained by both Colin and myself) that have native support for systemd. Maybe something more like: Contributors who have not already added native support for upstart, systemd, or OpenRC may wish to wait until the relevant Debian Policy is declared, by the Policy editors, to be ready. Early adopters should be aware that the requirements may change and their packages may require updates. > | 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. ] This seems fine. > | 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. Looks good. > | 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. Looks good. > | 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. I would drop (i) and (iv). (ii) is fine if and only if the sysv-rc maintainers *and* the init-system-helper maintainers both think that merging their packages is a reasonable thing to do; if not, I would also drop (ii). I don't see a need for the TC to force a package merger. (And, really, I'd drop it regardless since I think it's too far into the implementation weeds for the TC to need to have an opinion.) > | 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. Obviously I don't agree with this, as per previous discussion. > | 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. I'm not at all fond of this approach. Neither the upstart nor the systemd notification processes are so unreasonable as to warrant the TC explicitly asking the projects to change their designs. > | 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. ] I think we already covered this with "should" in the first sentence of this section without needing to make an explicit threat. > | 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. ] I'm not fond of this functionality either, but this feels quite strong. Do we really anticipate that this is going to be enough of a problem that we have to proactively forbid it with a TC ruling? > | 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). I'm not sure what the point of (b) is. I think (d) is too strong. Policy 4.13 currently says: If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible. using the Policy definition of "should" (meaning that it's a bug but not necessarily RC). I don't see why we would treat this instance of code copies any differently than we would treat any other instance in the archive. I think Policy 4.13 already covers this adequately and we don't need to say anything further in the decision. > | 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). ] This all seems fine. > | 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. I don't see anything objectionable about this, but I also don't really understand why it's important for us to say it. But regardless, I think this should be in brackets? It sounds like technical advice per the preamble. > | 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. ] This all seems nice in theory but rather problematic in practice. First, with my Policy Editor hat on, I object to Policy being placed in a blocking position. We are simply not responsive enough right now to hold that position responsibly. Multiple valuable, useful changes to Debian have happened without Policy changes, and with Policy only being added after the fact; consider, for instance, symbols support, triggers, and multiarch. I don't think we want to say that's not okay. Second, I think "take over" needs to be clearer. I assume that the intent of the term is to apply to cases where the new functionality conflicts with the old package and would make it impossible to use both at the same time. In other words, I don't think this should apply to, for instance, use of FDO desktop files for menus instead of the Debian menu system, since both can continue to work in parallel and neither takes over from the other in a way that prevents the other from working. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org