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

[Russ Allbery <rra@debian.org>]

Ansgar Burchardt <ansgar@debian.org> writes:

> So shipping a daemon without init scripts is better than shipping one
> with only a systemd unit? 

I don't believe such a daemon package (with no init script) should be
included in Debian at *all*, as a matter of not meeting the quality bar.

> Shipping a sysvinit script is only a "should" in Policy, unless you ship
> something for any other init system.

I think that's just that it's very difficult to write a Policy rule
explaining when something should have an init script and when something
should not.

> 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'm not surprised, but (and I have not investigated in detail) I suspect
at least some of these are bugs.  I think they should be RC bugs in cases
where there's no significant porting required, just no init script, but
I'm not on the release team and don't get to make that call.  I do think
they violate a Policy must.

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

I think you're reading Policy far too literally here; the intent is only
to cover unit files that are equivalent to init scripts, and none of those
things are.  I certainly support fixing that to make it clearer.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>