Russ Allbery wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > Russ Allbery wrote: > >>> It does, however, mean that it's a good idea for us to continue to >>> support sysvinit. > >> Not quite. It means we should maintain support for sysvinit *scripts* >> for the foreseeable future; there's no good reason for us to break >> support for /etc/init.d/* any time soon. > > There are other reasons to continue to support sysvinit: developers who > want to continue to use it, ports that want to continue to use it, and so > forth. > > I don't see any reason to drop support.
There's a difference between "dropping support" and "not mandating support". I'm entirely in favor of maintaining support for sysvinit for as long as people continue to be willing to spend their time on it. But we already, de-facto, let packages decide to not support it and only support systemd, if nobody cares enough to provide the additional code and support that would be required to do otherwise. (It seems easy enough to just write a "missing" init script, or accept a patch for one. It seems far harder to do so for a service that provides no daemonization support at all, expects socket or D-Bus activation, integrates with containerization, or otherwise makes use of the variety of mechanisms that make it far easier to write more capable and secure services these days.) This thread started with the question of "is it a bug to not have sysvinit support". And I think the answer, at this point, is "yes, but depending on the level of additional code and maintenance required, it might potentially be a wishlist bug". And there's a limit to how much maintainers are expected to deal with every wishlist bug, versus passing them upstream or seeking volunteers to help.
