Bug#727708: init system coupling etc.
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?
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.
> runit is an interesting case which I admit I hadn't really looked at
> before; I assume you aren't talking about its sysvinit compatibility
> mode, but rather the mode where you use it as pid 1 (e.g.
> init=/sbin/runit-init). In this case, I would point out that its
> documentation already says that you need to do the following when
> replacing pid 1:
Oh, sure, it's an artificial example, and I would be surprised if anyone
ran Debian in this model. But my point is that L is (unlike T) apparently
intended to be normative text as opposed to advice, but the normative text
is not sufficiently clear so that package maintainers know what they're
supposed to do, or (switching hats for a moment) Policy editors know what
they're supposed to be documenting.
> 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:
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.
If L passed, that's what I'd assume I was supposed to put in Policy. If
that's *not* what you mean, well, I think it's even more important to
clarify this somehow.
>> >> For the jessie release, all packages that currently support being run
>> >> under sysvinit should continue to support sysvinit unless there is no
>> >> technically feasible way to do so.
>>
>> "packages" here should probably actually be "software" for all the reasons
>> discussed elsewhere.
> I agree. Russ, how about this amendment?
> diff --git a/727708_initsystem/coupling-russ.txt b/727708_initsystem/coupling-russ.txt
> index 242505a..dfc1ded 100644
> --- a/727708_initsystem/coupling-russ.txt
> +++ b/727708_initsystem/coupling-russ.txt
> @@ -2,32 +2,30 @@
> Technical Committee under section 6.1.5 of the constitution. It does
> not constitute an override of maintainer decisions past or future:
>
> - Packages should normally support the default Linux init system. There
> + Software should normally support the default Linux init system. There
> are some exceptional cases where lack of support for the default init
> system may be appropriate, such as alternative init system
> implementations, special-use packages such as managers for non-default
> init systems, and cooperating groups of packages intended for use with
> - non-default init systems. However, package maintainers should be
> - aware that a requirement for a non-default init system will mean the
> - package will be unusable for most Debian users and should normally be
> - avoided.
> + non-default init systems. However, maintainers should be aware that a
> + requirement for a non-default init system will mean the software will
> + be unusable for most Debian users and should normally be avoided.
This seems fine.
> - Package maintainers are strongly encouraged to merge any contributions
> - for support of any init system, and to add
> - that support themselves if they're willing and capable of doing so.
> - In particular, package maintainers should put a high priority on
> - merging changes to support any init system which is the default on one
> - of Debian's non-Linux ports.
> + Maintainers are strongly encouraged to merge any contributions for
> + support of any init system, and to add that support themselves if
> + they're willing and capable of doing so. In particular, maintainers
> + should put a high priority on merging changes to support any init
> + system which is the default on one of Debian's non-Linux ports.
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.
> - For the jessie release, all packages that currently support being run
> + For the jessie release, all software that currently supports being run
> under sysvinit should continue to support sysvinit unless there is no
> technically feasible way to do so. Reasonable changes to preserve or
> improve sysvinit support should be accepted through the jessie
> release. There may be some loss of functionality under sysvinit if
This looks good.
> - that loss is considered acceptable by the package maintainer and the
> - package is still basically functional. All packages should support
> - smooth upgrades from wheezy to jessie, including upgrades done on a
> - system booted with sysvinit.
> + that loss is considered acceptable by the maintainer and the software
> + is still basically functional. All software should support smooth
> + upgrades from wheezy to jessie, including upgrades done on a system
> + booted with sysvinit.
I think we do mean package maintainer here as well.
> So, in my amendment, I intended this to be the "cooperating groups of
> packages intended for use with specific init systems", which language I
> think I borrowed from your proposal. If logind-208 Depends: systemd (or
> indeed if it's part of systemd), then that's fine, as long as it doesn't
> end up being required by something else that isn't so intimately related
> to the init system; in other words, a dependency on systemd doesn't
> become any less a dependency on systemd just because it happens to be
> spelled "Depends: logind" and there's only one provider available.
Oh, okay. That makes sense.
> 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.
> I think we should list situations where dropping sysvinit support would
> be permitted, as you do in the "exceptional cases" part of your
> proposal. Based on this thread, one such reasonable situation would be
> when a compatible implementation of the software in question remains
> available (thereby forestalling confusion about whether it's still the
> same software if it's been packaged under a new name).
Meh. I suppose we could, but I think it's hard to enumerate a complete
list. It would be things like:
* The upstream software no longer supports sysvinit as PID 1, it is not
reasonable from a security perspective to ship the version before that
change, and no one has done the work to reintroduce sysvinit support.
which is both rather a mouthful and only one of a variety of related
possible cases.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: