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

Re: Is missing SysV-init support a bug?

Guus Sliepen wrote:
> On Fri, Aug 26, 2016 at 12:11:13AM +0200, Sven Hartge wrote:
> > I just saw the new conntrack-tools (1:1.4.4-2) package in Sid, which
> > has as a change
> > 
> >   * [917beed] conntrackd: get rid of the sysvinit support
> > 
> > and I wondered, if this is a bug (and at what severity) or not.
> Yes, this is a bug and I think you can give it at least priority important.
> While Debian has switched to systemd as the *default* init system, it is
> not the only one it supports. Package maintainers should not remove
> support for other init systems. If they feel they are not up to
> maintaining the sysvinit scripts, they should ask for help instead of
> removing them.

I looked up the answer to this recently (because I wanted to do exactly
what the conntrackd maintainer had done).

The relevant text from the policy manual, §9.11:

    Packages may integrate with these replacement init systems [i.e.,
    init systems which are not sysvinit] by providing
    implementation-specific configuration information about how and when
    to start a service or in what order to run certain tasks at boot
    time. 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, as this is the only start-up configuration
    method guaranteed to be supported by all init implementations.

The relevant TC decision was two years ago in #746715:

    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.


However, that was two years ago. How long should we be expected to
continue maintaining sysvinit scripts?

Robert Edmonds

Reply to: