Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

[Ansgar Burchardt <ansgar@debian.org>]

Russ Allbery writes:
> 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.

Policy requires an init script with the same name for *every*
init-specific job.  That is probably not intended, but what it currently
says.

>> 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.

So shipping a daemon without init scripts is better than shipping one
with only a systemd unit?  Shipping a sysvinit script is only a "should"
in Policy, unless you ship something for any other init system.

> 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).

That exception does not exist in Policy; there is only an exception for
packages provided by the init implementation itself.  Policy currently
requires the "Loose coupling of init systems" option of
https://www.debian.org/vote/2014/vote_003 as far as I can tell as
services must be able to run under sysvinit.

We already have several packages only shipping systemd units, including
with socket activation (I did not check if any services cannot be
configured to not listen on their own, but I wouldn't be surprised).
Those with socket activation include: chasquid, cockpit-ws, erlang-base,
hddemux, ibacm, rkt, snapd, sssd-kcm, tang, tinysshd.

I wouldn't be surprised to see more services require systemd's socket
activation in the future.

(Also, see DBus-activated services, inetd-style socket activation,
.timer units with their associated .service; there is no need for a
sysvinit script in these cases, but Policy requires 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.

Hmm, I'm slowly getting tempted to suggest that after reading one more
of the "systemd is Redhat/NSA cancerware" mails on debian-user@.  Giving
up sysvinit support might make those people go away and that alone is
slowly getting worth it for me...

Oh, and another arrived on -devel@ just now.

Ansgar