Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
Hi,
On Tue, Oct 16, 2018 at 06:49:56PM +0200, Ansgar Burchardt wrote:
[...]
> +---
> | However, any package integrating with other init systems must also
> | be backwards-compatible with sysvinit by providing a SysV-style init
> | script with the same name as and equivalent functionality to any
> | init-specific job
> +---[ Debian Policy, 9.11 "Alternate init systems" ]
>
> I propose to drop the requirement for the following reasons:
[...]
I don't really disagree with anything Ansgar has already said, but would
like to present a different view mostly for potential "food for thought".
It seems obvious to me that the above policy snippet was written in a
time when the universe revolved around sysvinit. In current day and age
sysvinit itself would be an "Alternate init system". We could update the
snippet to say that any package providing support for an alternate init
system must also provide systemd units if we wanted to modernize this
part of policy. On the other hand, that should probably be "should"
rather than "must" since we don't want to make numerable
un(der)maintained packages still not providing native systemd units
insta-RC-buggy.
(I'm not sure if targeting very specific issues and documenting things
related to systemd or init systems are worth it when we still miss the
"large picture" related to systemd in policy. On the other hand maybe
we'll never get there unless we start small and document things piece by
piece. I'm still leaning towards thinking just dropping this section is
better than doing a direct translation of it to the current systemd
reality which might just end up being confusing and help noone.)
Regards,
Andreas Henriksson
Reply to: