On 12/08/2016 13:43, Tom H wrote:
>> On 12/08/2016 11:49, Tom H wrote:
>>>
>>> Off-list
>>>
>>> Install
>>> runic-init
>>> in order to restore
>>> /sbin/init
>>> and
>>> /sbin/runit
>>
>> Thanks for the suggestion. Unfortunately 'runic-init' it is not in
>> 'ascii' and googling didn't help neither.
>
> You're welcome.
>
> runit-init should be in ascii because it's in stretch.
>

Yes. that is the one which conflicts with sysvinit-core

>
> It's version 2.1.2-5.
>
>>From the changelog of 2.1.2-4:
>
> New binary package 'runit-init', that provides /sbin/init replacement
> out-of-box.
>
> I'd say that it's badly packaged. For sysvinit, there's
>
> - sysvinit, which provides "/lib/sysvinit/init" so you can boot using
> sysvinit by adding "init=/lib/sysvinit/init" to the kernel cmdline
>
> - sysvinit-core, which provides "/sbin/init"
>

Thanks for this tip. BTW, sysvinit is a transitional package for people
who are not so sure about systemd-init. So that will go away in not too
distant future.

>
> It would be more work to set things up like sysvinit because it would
> involve others making changes to their packages. For example,
> sysvinit-core and systemd-sysv would have to have conflicts with
> runit-init. Even then, it wouldn't quite right because runit-init
> doesn't provide "/sbin/halt" and friends. So it's simpler to create
> runit-init and hope people using runit as pid 1 install it when
> upgrading.
>

And in my opinion, it would be even more simpler if 'runit-init' would
just divert the original sysv runlevel, halt/reboot and shutdown befor
it drops it own shims for these modules onto the disk. This means that
the user has choices and he can work with symlinks just as he has to
with runit-init anyway.

Many thanks

Fred