On 15/01/16 14:13, Dmitrii Kashin wrote:
Alec Leamas <leamas.a...@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
