Bug#727708: init system coupling etc.
On Wed, Feb 19, 2014 at 06:55:31PM -0800, Russ Allbery wrote:
> Colin Watson <cjwatson@debian.org> writes:
> > What I mean by this is that software (with all the exceptions above) may
> > not be shipped in a configuration where you can only use it with certain
> > init systems. For service startup, that just means shipping sysvinit
> > scripts. For other interfaces, that means restricting ourselves to the
> > subset of interfaces that people have figured out how to make work with
> > other init systems as pid 1.
>
> If you do mean that all packages with init system configuration have to
> ship sysvinit scripts, I wish the wording would actually say that. This
> potentially matters in the long run. For example, consider a hypothetical
> future world in which systemd, upstart, and OpenRC are packaged for Debian
> and sysvinit has gone away. In that world, I would maintain separate
> configuration for systemd, upstart, and OpenRC, since I consider
> maintaining those three separate files to be easier than maintaining a
> sysvinit script. Is that permitted? If it is permitted, does my package
> become instantly buggy when someone packages openlaunchd for Debian?
I've gone back and forth in my own mind about how/whether we ought to be
sunsetting this stuff, so apologies if this contradicts something I've
previously said. My preference is (to borrow a phrase from British
constitutional law) that the TC should not be trying to bind its
successor. I'm entirely happy for us to set policy (or give advice,
whatever) based on how things stand at the moment, and revisit it later
when the landscape changes.
I know we're all tired of this debate at the moment. But if and when
sysvinit goes away, I think it'll be relatively straightforward by
comparison to establish revised policy in light of that, and it will be
much clearer then what that policy ought to say than it is now. There
doesn't seem any danger that we'll forget about this.
My instinct is that in the new world you outline where we
(hypothetically) have no common subset of service configuration among
init systems, we probably ought to end up with an explicitly supported
list of init systems (determined at a more lightweight level than the
TC) and any new init system would have the job of fleshing out enough
support in the archive to convince us to add it to that list. But I
explicitly don't want to try to lay out something like that now; we
don't need it yet and it would be unnecessarily contentious.
Would it improve things if we added an informative paragraph such as
this? (I'm not necessarily asking whether it would lead you to rank
this option higher, just whether it makes the intent clearer.)
This policy is intended for the current situation where most services
can still easily include support for multiple init systems by means
such as shipping a sysvinit script. If this changes then we expect to
revise this policy or ask the policy editors to do so.
> The second is also ambiguous, albeit less so. "Figured out how to make
> work with other init systems" != "figured out how to make work with all
> init systems." It's possible to imagine services that work with upstart
> and systemd but don't work with sysvinit, although I don't know of any
> currently.
This is a situation that some people have raised but that I honestly
don't consider interesting. Upstart and systemd are different enough,
and Upstart takes a minimal enough approach to the interfaces it offers,
that a service that (non-trivially, i.e. not just with straightforward
job/unit files) supports both has IMO demonstrated enough extensibility
that it wouldn't be hard to port to other things. Consider the single
cgroup writer in cgmanager as an example: that's a separate add-on
service that has nothing Upstart-specific about it and should work just
as well with other init systems.
I understand that there is a theoretical ambiguity here, but I'm not
sure how to tighten it up and I'm not keen on spending time doing so
since I think it will remain theoretical.
> > Similarly, if somebody uploads a new init system to Debian which has no
> > sysvinit compatibility and thus does basically nothing useful to start
> > with, then that system is de facto RC buggy in that it can't boot a
> > useful Debian system, and it shouldn't be other packages' responsibility
> > to deal with the fact that that init system has no reasonable migration
> > path.
>
> > I will concede that my amendment is not terribly explicit about this.
> > I'm not sure how to make it more explicit without cut-and-pasting the
> > above into it, which I think would be a bit much. Russ, I know you said
> > you weren't likely to vote for this, but I don't suppose you could
> > suggest some language which at least makes the meaning reasonably
> > watertight to you per the above?
>
> I think what you're trying to say, from the above, is:
>
> All software that needs init system configuration must include
> sysvinit scripts. Software may not require any functionality from the
> init system that cannot be provided via init scripts, although
> degraded operation is tolerable. The exceptions to this are as
> follows:
I would be fine with this, perhaps with s/require/have a hard
requirement of/ for the sake of emphasis, and s/via init scripts/via
init scripts or other similar compatibility mechanisms/. But it's
really Ian's proposal; Ian, what do you think?
> Also, I assume that this language intends to say that this is forever. In
> other words, no package is ever permitted to drop sysvinit scripts,
> regardless of what init systems are in use in Debian, at least until the
> TC issues another ruling.
See above.
> I think we do actually mean package maintainers here. I at least don't
> see any real change by dropping the word "package" and I'm not sure it
> makes matters any clearer.
[and similar] OK, I don't mind either way on that. Could you go ahead
and commit the necessary adjustments to git?
> > My objection to "unless there is no technically feasible way to do so"
> > is that it's another way of writing "it's too hard", which could mean
> > almost anything, and thus the "should continue to support sysvinit"
> > stipulation is toothless: all a maintainer needs to do is say that it
> > isn't technically feasible to carry significant patches against upstream
> > even if somebody else writes them, and that's that. Now, maybe the
> > "Reasonable changes to preserve or improve sysvinit support should be
> > accepted ..." sentence covers this, but it seems awfully woolly to me.
>
> Well, it's technical advice. It's therefore toothless by definition;
> that's why it's advice. :) Yes, the maintainer could use that logic to
> ignore it, or the maintainer could just ignore it because it's advisory
> and not normative, regardless of how it's worded.
>
> This is probably my standards background showing here, but I try to
> maintain a clear distinction in writing between normative and
> non-normative text. Advice is non-normative. We expect package
> maintainers to use their good judgement, augmented by the guidance of the
> advice. If they don't, then the release team may have to say "um, no, RC
> bug" or the TC may have to consider an override, which is true no matter
> how it's worded.
>
> I don't think there's a point in trying to put teeth into a statement
> that's explicitly technical advice. This is not the point in the process
> in which teeth are involved. That would be maintainer overrides, which
> this is not.
>
> Debian contributors are smart people. I really don't think anyone is
> going be confused by the difference between "not technically feasible" and
> "not technically convenient." And I *want* maintainers to make good
> judgements about what is technically feasible and what isn't.
OK. It still makes me itchy about the details of the message it's
sending (and the point of technical advice is exactly to send a
message), but I take your point about the different character of
informative text, and I don't have a better suggestion right now.
--
Colin Watson [cjwatson@debian.org]
Reply to: