On Fri, 26 Aug 2016 14:14:25 +0100 Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
> Sam Hartman writes ("Re: Bug#835507: Please clarify that sysvinit support
> decision is not going to expire"):
> > I don't want to make a blanket statement that it's a bug not to include
> > an init script. The systemd package includes a number of daemons and
> > services and installs no init scripts, and no really, that actually is
> > the right answer for that package. Policy should basically means bug of
> > normal severity. (I've always wished that the policy people would be a
> > bit more nuanced especially when taking a term from RFC 2119, which
> > more-or-less already includes the nuanced language they need, but
> > people seem to do a fairly good job of accepting the nuances even though
> > that's not quite what policy says.)
>
> You could say that missing sysvinit support is a bug unless there's a
> good reason why this particular package ought not to support sysvinit.
This seems like a completely reasonable thing for Policy to say. It
actually doesn't say that today (see Policy 9.11), but I think it
should.
Assuming Policy does say that, then that seems like a sufficient
justification to 1) file a bug and 2) provide or seek out help fixing
that bug. (Right now, Policy provides enough justification to file a
"Severity: serious" bug, but that doesn't seem reasonable; a
normal-severity bug does, though.)
In the case of conntrack-tools, has anyone actually filed a bug, or
offered to help?
> > I think including 6.1.5 language saying that we encourage maintainers to
> > merge patches adding support for init systems including init scripts
> > would be valuable.
>
> That would be good.
>
> I think what is really needed is a clear statement from the TC that
> support for sysvinit should not be regarded as transitional or
> time-limited.
That's a question of available volunteer time. I don't think sysvinit
support should be regarded as "time-limited"; I don't, for instance,
think "that was two years ago" in isolation serves as a reasonable
argument for ignoring sysvinit. However, I do think it's reasonable to
expect people who want it to work to provide assistance keeping it
working. For instance, if someone filed a bug on the sysvinit support
in a package, it seems reasonable for the maintainer to tag it "help".
And if upstream of a package starts requiring systemd and drops support
for sysvinit, I think it's reasonable for a maintainer to send a note to
debian-devel and similar asking for volunteers to maintain a version of
that software with sysvinit support, and to talk with those volunteers
about what shape that maintenance should take (e.g. working with
upstream, providing a new upstream, providing patches to the existing
pakage). Dropping such support the moment upstream does without any
warning seems unreasonable.
