Russ Allbery writes ("Bug#727708: init system coupling etc."):
> 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 draft text in my option says:
In general, software may not require a specific init system to be
^^^^^^^^^^^^^^^^^^^^^^
pid 1. The exceptions to this are as follows:
I think this leaves open the possibility that software might not work
with certain init systems. I'm not trying to say that all software
must work properly with all init systems, no matter how experimental
or broken. (Although that would be nice of course.)
In particular, I don't think this is imposing a requirement for
daemons to work with init systems which do not provide at least a
compatibility mode for common interfaces (at the moment, the common
interfaces for this include sysvinit scripts, inetd.conf and perhaps
something else I haven't thought of).
In practice what I would like to see is a kind of more powerful
compability mechanism that is better able to exploit the better
behaviours of more modern daemon supervisors.
But at the moment the main compatibility mechanism sysvinit scripts,
and all of our init systems support sysvinit scripts. So that means
that all packages should ship sysvinit scripts. Work is ongoing on
other kinds of compatibility approaches. (It's not even necessary for
all daemon packages or all init systems to use the same compatibility
approach.)
I'm relaxed about the idea of packages having to ship sysvinit scripts
indefinitely. Shipping sysvinit scripts does not mean that they have
to be handwritten. It would be perfectly feasible for a daemon which
only supported a sensible non-forking startup approach to provide an
init script which is autogenerated from some kind of meta information
(and to use a helper tool for daemonisation).
I think there's a clear segment of opinion in the project and amongst
our users who want to keep the traditional sysvinit approach. It's
not clear whether a minority or a majority will actually want to run
sysvinit indefinitely, but even if we think other approaches are
better that doesn't mean we should be forcing them on everyone.
> 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 now, yes, you should put that into policy. If we later come up
with a better compatibility approach, policy can be amended. The TC
decision is defining the objectives, not the details.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21254.1984.23537.903...@chiark.greenend.org.uk
