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.
(https://lists.debian.org/debian-devel-announce/2014/08/msg00001.html)
However, that was two years ago. How long should we be expected to
continue maintaining sysvinit scripts?
--
Robert Edmonds
edmo...@debian.org
