Bug#727708: init system discussion status
Russ Allbery writes ("Bug#727708: init system discussion status"):
> 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.)
Thanks. I agree with much of what you say. I will deal with your
comments again in more detail later, particularly the bits I don't
disagree with, but for now:
> 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.
I'm not sure what kind of things you are proposing should be in the
resolution text (or, what in my proposal is wrong). Is it not
sufficient to say that people should accept openrc patches as and when
the openrc policy is done ?
> > | 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.
Ansgar said something similar on IRC. I didn't feel it worth
mentioning but if you want it too then I'm convinced.
> > | [ 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.
I don't mind dropping this part entirely.
Certainly I don't think we can make this decision now.
> One possibilty is to explicitly say that we'll make it ourselves after the
> jessie release.
I don't want to do this in case it turns out to be uncontroversial.
> > | 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.
I think that's not the right the question. The real question is this:
Are the protocols offered by systemd and upstart each so plainly
reasonable, that we are willing to overrule a maintainer who feels
they protocol they are asked to support is too ugly or burdensome ?
Are such a maintainer's objections so unreasonable ?
The init system is a core facility. Compatibility with a wide range
of other projects with a wide range of different opinions amongst
their developers is imporant. Supporting one more protocol is very
easy for the init system.
In practice if systemd and upstart each implement each other's main
protocol, I would expect very few if any packages to remain
unsupported.
For me the objection that to invent a new protocol would be
multiplying standards carries no weight. There is little cost to
these competing standards, and we already have at least eight in the
world (sd_notify, SIGSTOP, systemd socket activation, upstart socket
activation, upstart "expect fork", daemon(3), inetd, and what systemd
calls "simple").
> > | 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.
I would like to include this because it will stiffen our resolve. It
also includes the important point that it is up to the maintainer to
justify non-inclusion, not the other way around.
> > | 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?
The main practical reason for ruling this out, and converting existing
packages, is that not all the ports of upstart can be expected to
implement the underlying strace mechanism used by upstart to implement
these.
The project needs to make a choice between requiring all our ports to
support those protocols (which are very unpleasant, and also hard to
port), and forbidding packages from usign them. Having the protocol
for a single init system depend on the platform would be too awkward
IMO. So something about this needs to be in policy.
I'd rather deal with this here in the TC having done all the research
than remand it to the policy list and then perhaps having it come back
when it turns out that there are differing opinions about the value of
the non-Linux ports, etc.
(This is advice on policy, of course, not a binding decision.)
> > | 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.
Yes, I just failed to bracket it.
I want to put this in because I'd like to be able to drop sysvinit in
(its current form at least) in jessie+1, without duplicating or
triplicating all the init system integration work.
Putting this in here sends a signal that we would look favourably on
some kind of compatibility layers. I don't think it's essential if
people object to it.
> This all seems nice in theory but rather problematic in practice.
>
> [...] 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.
I don't agree. Unless we either have a compatibility shim, or a
policy decision to transition, every package ought to be required to
provide something in the Debian menus. Isn't this situation analogous
to the mime-support argument where we required a package to reinstate
a mime entry ?
Ian.
Reply to: