On Thu, 2016-08-25 at 18:43 -0400, Robert Edmonds wrote: > 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.
Was that changed since the default init system was changed? It pretty much still reads like Policy still assumes that sysvinit is the default init system. It also still mentions upstart in 9.11.1; will file a bug for that. If it wasn't changed, just s/sysvinit/systemd/ mentally ;) It's not the only place where Policy lags behind what is actual practice. > 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? Well, the quoted decision doesn't suggest active maintenance. Just ignore it, but don't remove it (random additional configuration(!) files shouldn't be too bad). So keep them, ignore them and in 10 years we will eventually remove them ;) Ansgar
