On 2016-01-15 at 09:45, Alec Leamas wrote: > On 15/01/16 14:13, Dmitrii Kashin wrote: > >> Alec Leamas <leamas.alec@gmail.com> writes: >> >>> Dear list, >>> Given all this: would it be OK to drop the sysV files in a >>> stretch update? >> >> I suppose it's not okay, because you'll get a lot of bug reports >> from non-linux based debian distributions. And if it's not your >> business, and you don't support sysv scripts, then it will >> eventually become a problem for developers of these distributions. >> >> I wanna remind that systemd as the default is an experiment. It can >> be finished in a while. So it's important to safe the support for >> other init systems. While I agree with the sentiment, I'm not sure I've heard that choosing systemd as default was an "experiment" before now, at least any more than any Debian choice is an experiment (in that the project can decide to switch away from it if it doesn't work out well). >> Btw, I'm a user of Debian Jessie, and I see then now Debian keep >> an ability to work without systemd. I'd like it to be so in the >> future. > > So, here is three things: > > Support for non-linux based debian distributions. Perhaps this could > be handled by packing current scripts in /usr/share/doc, so they are > available for downstream packaging? Besides that, what says policy > decisions on this issue? It's not only about downstreams. What about e.g. Debian-kFreeBSD, or Debian-Hurd? Both are theoretically official Debian, as far as I understand matters, rather than being downstream distros - but neither one is supported by systemd. > Support for users not using systemd. I understand that such users > will be unhappy without the scripts - but am I obliged under current > policy decisions to maintain this configuration? My understanding from the past debates is that you're not obliged to maintain sysvinit scripts, but that if other people want to do the work and send in patches to add / update / maintain such scripts, you don't get to reject them - or at least not on the grounds that sysvinit is not supported. That would seem to imply, in turn, that you shouldn't drop existing sysvinit scripts from the package, unless they're known to already be broken badly enough that not having any would be an improvement (although I don't think I've seen this specifically addressed in past discussions). You wouldn't be obliged to continue to maintain and update them, however, and IMO - in the absence of someone who _is_ doing that - you'd be fine to put in a warning that using them is unsupported and not recommended. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature