Bug#835507: Please clarify that sysvinit support decision is not going to expire
]] Josh Triplett
> On Fri, 26 Aug 2016 14:14:25 +0100 Ian Jackson <ijackson@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.
This sounds pretty reasonable. Trying to enumerate the various reasons
why (or why not) a package does/doesn't support sysvinit doesn't seem
like a great way to spend our time.
> 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.)
Maybe important since it's removing existing support, but I'm more
interested in fixing bugs/preventing them being created in the first
place than discussing severities.
[...]
> 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".
I agree on this too. To the extent it should be considered
time-limited, it should be «until N releases after sysvinit is removed»
or somesuch, if that happens.
> 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.
Somewhat depending on the package and level of integration with
sysvinit/systemd, but I'm pretty much in agreement with you here as
well.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: