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.
