[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Removing sysV init files

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

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

   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

Reply to: