Russ Allbery <r...@debian.org> writes: > Ansgar Burchardt <ans...@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
