]] Josh Triplett > 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.
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