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

[Ansgar Burchardt <ansgar@debian.org>]

Steve Langasek writes:
> On Wed, Oct 17, 2018 at 10:07:44AM +0200, Ansgar Burchardt wrote:
>> 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 actually don't agree with this policy proposal - I think that if we are
> going to support non-systemd init at all in Debian, it needs to be more than
> lip service, and that means policy needs to spell out that maintainers have
> a responsibility to help hold the line

Well, Debian supports several architectures besides amd64 and it works
okay without there being a Policy requirement of "if it works on amd64,
it *must* work on mips64el".

Of course it also helps that we require release architectures to have
porters.  sysvinit on the other hand doesn't even really have a
maintainer for the past years (last maintainer upload in 2015, 11 NMUs
since then)...

> The snapd service as implemented upstream generates and manages systemd
> units, including both .service and .mount units.  Making snapd work with
> non-systemd init would be a non-negligible upstream porting effort.
>
> Snapd is also not straightforwardly portable to non-Linux kernels, which
> IMHO is the principle reason that Debian should continue to care about
> non-systemd init at all.
>
> Should Debian refuse to allow a package into a stable release ("RC-buggy")
> whose upstream has made technology decisions that tie it to a particular
> sysvinit-incompatible init system?

I think it is fine (even though Policy says snapd is not okay).  Just
like we allow packages that work only one some architectures (or even
only one), or that might work in theory also on other architectures, but
nobody bothered to fix them.

All of this works fine without a "must" in Policy for supporting
alternative architectures that then would need strange exceptions.

Given this works mostly fine, I don't think we need more than a "should"
for init scripts either.

If you disagree, please explain why it seems to work for architectures,
but would not for providing init scripts.

Ansgar