Bug#727708: init system discussion status
Ian Jackson <ijackson@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: