Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
Ansgar Burchardt <ansgar@debian.org> writes:
> a. tor@.service has no init script with the same name. This should be
> fine. (Note: there is also both a "tor.service" and "tor" init
> script.)
Presumably this is fine for the same reason as b.
> b. ssh.socket for systemd has no equivalent in sysvinit at all.
> This should be fine.
This is not a good example, since openssh-server provides an init script
that provides "equivalent functionality" in the form of running sshd as a
daemon, and socket units are not equivalent to an init script and
therefore aren't what this part of Policy is talking about.
> c. It is better to ship integration with some init systems than
> no integration at all. (Including sysvinit scripts at all is not
> required, only when any other integrations are provided.)
I don't agree with this. Until such time as we make a project-wide
decision to drop support for sysvinit, providing an init script for
straightforward daemons is part of packaging a daemon. If people are
unwilling to do this work, I don't believe we should accept the package in
Debian. In other words, I personally believe not providing an init script
should be an RC bug (as Policy currently indicates) given the current
project stance on init systems, except for the standard exception case of
packages that are specifically designed to only be meaningful with systemd
for which making them work with any other init system would require
significant porting (not just writing a simple equivalent init script).
This is not the sort of thing that we should be dropping on an ad hoc
basis given the project decision to support multiple init systems, since
if we give up this principle it will be *extremely* hard to re-establish
it.
That doesn't mean that we can't decide to drop formal sysvinit support.
It does mean that we should do this properly, as a project-wide decision,
which is way, WAY beyond the scope of Policy and is *absolutely not*
something that we're going to be able to decide here on this mailing list
or in this bug report.
> d. Some sysvinit scripts might start multiple services at once,
> but this might be split into multiple units in other systems.
> This should be allowed.
I think tweaking the wording to account for this is reasonable.
> e. It is unclear what "equivalent functionality" implies. Does this
> include sandboxing features? Socket activation (which might be
> important for startup order)? Using the same file for configuration
> (some services can be configured in /etc/default/* for sysvinit,
> but use overrides for systemd)?
This is a fair point, and I think we could certainly change the wording
here to reflect that it's unreasonable to expect 100% equivalent
functionality; there are features that sysvinit simply doesn't support,
for instance.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: