Auteur: Rob Owens Datum: Aan: dng Onderwerp: Re: [DNG] OpenRC and Devuan
----- Original Message ----- > From: "parazyd" <parazyd@???> > On Tue, 03 May 2016, Rob Owens wrote:
>
>> ----- Original Message -----
>> > From: "KatolaZ" <katolaz@???>
>>
>> > But do we really need all that complication? Couldn't we just leave
>> > the initscript of each init system in a different directory and *tell
>> > the init system* where they are to be found? This will allow a much
>> > easier coexistence of different confs.
>> >
>> > Basically, everything related to sysvinit, stays in /etc/init.d, and
>> > sysvinit knows it has to look there. OpenRC stuff stays in
>> > /etc/openrc, and openrc knows it has to look there for its scripts.
>> > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look
>> > there for its stuff. We add the next-init-system, it will have its
>> > scripts in /etc/<the-next-init-system-damn-name>.
>>
>> 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).
>>
>> 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.
>>
>
> This is unnecessary. In OpenRC you can easily specify $SYSCONFDIR and
> set it to /etc/openrc. Then all will be found inside, and the system
> will already know what to do, without symlinking.
Yes, but then when an openrc user wants to start/stop a service, he
cannot do '/etc/init.d/myservice start' like he could do on any other
OS using openrc. He'd have to do '/etc/openrc/myservice start'. Not a
really big deal, but I think it's undesirable to make Devuan's openrc
procedures different (especially when it could be addressed with a
simple symlink).