On Tue, 03 May 2016, Steve Litt wrote:

> On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> Rob Owens <rowens@???> wrote:
>
>
> > I agree with putting each init in its own directory, but sysvinit
> > should not own /etc/init.d. sysvinit stuff should go in /etc/sysvinit
> > and by default /etc/init.d should be a link to /etc/sysvinit/init.d.
> > The reason is that other init systems may expect to own /etc/init.d.
> > For instance, openrc puts all its scripts in /etc/init.d (at least on
> > Funtoo it does).
>
> I don't remember any other init wanting to use /etc/init.d, EXCEPT
> OpenRC, or EXCEPT when they want to use the sysvinit init scripts, and
> the only one I know that wants to do that is systemd.
>
> I wouldn't change sysvinit's expected files one little bit. Everyone
> assumes that /etc/init.d belongs exclusively to sysvinit. Any change to
> sysvinit would require lots of testing, and who needs that headache?
>
> >
> > Even though sysvinit is our default init system these days, we should
> > not design Devuan such that it is difficult to change that in the
> > future. So put sysvinit stuff in its own directory just like all the
> > other inits.
>
> If you leave sysvinit's directories exactly as they exist now,
> switching back and forth between sysvinit and runit is trivial. Same is
> true of s6 and Epoch.
>
> Because OpenRC has seen fit to intermix their init scripts
> with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> OpenRC be kept somewhere besides /etc/init.d.

The problem with this is Debian itself. They insist on using LSB init
scripts and in my opinion that they are somewhat different than what OpenRC
wants.

(For me at least) openrc initscripts are simpler, and also
for respecting the openrc way(?) I wish to keep it in /etc/openrc. This
way, with or without debhelper scripting OpenRC should work much more
easily. The only thing then is that the package maintainers would have
to include new initscripts in their packages, which might or might not
be cumbersome for them.

sysvinit should and will just stay where it already is. There is really
no point in changing it's current configuration when other alternatives
offer very easy ways to work around it.

--
~ parazyd
0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274