Sam Hartman writes ("Re: Bug#835507: Please clarify that sysvinit support decision is not going to expire"): > Ian, quick question for you because you might know the answer off the > top of your head. Does running stretch with sysvinit as your init > system work reasonably well, or at least work well enough that there are > a small number of bugs we will likely be able to fix in the stretch time > frame? What I say below is predicated on the assumption that init > scripts are basically functional for stretch. If that's not true I'd > need to rethink my position.
I am running stretch with sysvinit on my laptop. It seems to work for me. I haven't conducted any kind of systematic survey. > 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. > I do *not* want to get into describing all the cases where it is a bug > to not include an init script, nor do I want to get into all the cases > where it isn't. I don't think that's necessary. The situations where this is causing friction (see debian-devel) are not the unusual cases where the package is part of systemd (or indeed is glue for another init system - see what's done in a few cases for runit). A statement of the general idea, even with a broad room for exceptions, would be sufficient. > 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. Otherwise sysvinit users (and advocates) have to have tiresome discussions one package at a time - discussions where the maintainer inevitably starts repeating the claims that sysvinit is obsolete and should be thrown away now. In the political context of the init system wars, those kind of statements are extremely agressive. Coupled with the fact that the maintainer is in a position of power, this generates justifiable fear and anger in systemd's opponents. So, sadly, I think the TC needs to reiterate and reinforce its earlier general message. Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.