Package: debian-policy Version: 4.2.1.2 Severity: normal This requirement is currently included in Debian Policy:
+--- | However, any package integrating with other init systems must also | be backwards-compatible with sysvinit by providing a SysV-style init | script with the same name as and equivalent functionality to any | init-specific job +---[ Debian Policy, 9.11 "Alternate init systems" ] I propose to drop the requirement for the following reasons: 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.) b. ssh.socket for systemd has no equivalent in sysvinit at all. This should be fine. 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.) 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. 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)? If one tries to accomodate all of this, only something along the lines of "if there is a init-specific job and an (in some way) equivalent SysV-style init script then both should have the same name" remains. Ansgar
