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. 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?
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?
"systemd is an experiment". Well, the future can bring any changes. Frankly, we need to adapt when the changes come, if they come. IMHO, what we can about this is, again, to ship the unmaintained scripts in /usr/share doc.
I might add that this is not as simple as some service changing from an init.d script to a corresponding .service files. The upstream package has another service structure, socket activation and other things which are not easily reflected in the sysV scripts. Also, all existing documentation presumes systemd. So, while the sysV scripts exists and perhaps "works" in a basic sense they represent sub-optimal user experience. This is what makes this hard.
Thoughts? --alec