Ansgar Burchardt <ans...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>