[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#835507: Please clarify that sysvinit support decision is not going to expire

On Fri, 26 Aug 2016 12:55:56 +0100 Ian Jackson <ijackson@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

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?

Reply to: