On Fri, 26 Aug 2016 12:55:56 +0100 Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: > So: would the TC please clarify that the decision that > > For the record, the TC expects maintainers to continue to support > the multiple available init systems in Debian. That includes > merging reasonable contributions, and not reverting existing > support without a compelling reason. > > still stands, and that the answer to this queston > > However, that was two years ago. How long should we be expected to > continue maintaining sysvinit scripts? > > is "indefinitely, and specifically until a contrary decision by the > TC" (subject to quibbles over the exact meaning of "maintaining"). > > Or to put it another way: > > The answer to "is missing sysvinit support a bug" is "yes, and > it will continue to be regarded as a bug until further notice". > > Of course a maintainer is not required to personally fix every bug, > but a maintainer should not introduce bugs without good reasons, and > should merge reasonable bugfix contributions.
Policy *already* defines it as a bug (in terms of failing a "must") to not supply sysvinit support. Quoting Policy 9.11: > 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, as this is the only start-up configuration method > guaranteed to be supported by all init implementations. An exception > to this rule is scripts or jobs provided by the init implementation > itself If anything, Policy needs some fixes to even allow for the *possibility* of packages that can only work with systemd. There's no current exception in Policy that allows for packages that specifically depend on systemd functionality unavailable in sysvinit. For instance, a package that uses socket activation and intentionally has no support for running as a standalone daemon would likely want to integrate with inetd as an alternative rather than integrating with sysvinit, but Policy doesn't actually allow a package to do that. Today it'd be a Policy violation to ship a package that supports running via either systemd or inetd, because running via systemd triggers Policy 9.11 and thus requires a "SysV-style init script", even when that wouldn't be appropriate. The reaction to every single instance of someone finding it a pain to maintain sysvinit support should not be "as a reminder, the TC has a giant hammer and will hit you with it". The reaction should be "are there people willing to *help* maintain sysvinit compatibility, who actually use it, who will notice when it breaks, and who will send patches?" And the answer to "how long should we continue maintaining sysvinit scripts" is "as long as someone is willing to step up and do the work". (That's also, for instance, the answer to "how long should we maintain an architecture", and many other similar questions.) I do think that developers (*not* the TC) with an interest in sysvinit support should explicitly say that if anyone needs help maintaining sysvinit support for their package, they'd be willing to volunteer to provide such help. Anyone willing to volunteer for that?
