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
