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

[Ansgar Burchardt <ansgar@debian.org>]

Russ Allbery <rra@debian.org> writes:
> 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.

Policy says the opposite though...

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

Yes, that's why I suggest the one rule that tries to state that
sometimes a init script *must* exist is a bad rule.

Even without the "must" in 9.11, there is still the recommendation that
init scripts "should" be provided (9.3.2).  According to policy that is
enough for a bug.

Unless one assumes bad faith that seems to be good enough to me.

Otherwise one gets to enumerate exceptions or has to forbid packaging
applications that only work under systemd.  As far as I know snapd
delegates some work to systemd and wouldn't work under sysvinit even if
you start it from an init script...

We could of course also say that this decides the "snap" vs "flatpak"
decision ;-)

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

If one of them requires socket activation, would it be a RC bug in the
package or a RC bug in alternative init systems such as sysvinit to
provide no means to start such services?

If one of them requires other systemd features and doesn't work under
sysvinit anyway, why should an init script be required?

I also note that Policy currently has no "where there's no significant
porting required" exception and as I said earlier I don't believe in
enumerating exceptions if one can just use "should".

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

I think the "should" from the earlier section on init scripts is
enough. Then one doesn't need to write more complex rules here.

Ansgar