Hi Martin,

>Hmmm I think the runit-services package (it is not called runit-scripts)
>uses a nice approach with cpsv. What do you disagree with?

Normally your runit services should be under /etc/sv, with the ones you want
to run symlinked into /etc/runit/runsvdir/<runlevel>. Now runit-services puts
them into /usr/share/runit/sv (so that /etc/sv is not crowded with all the
services without a corresponding installed package), and provides the helper
cpsv to copy those into /etc/sv, and create the symlink to enable them.

There are 2 separate tasks here that the command does:
- Shadowing /etc/sv from a separate dir. I don't think this is really
necessary to be honest, it's more like a convenience feature.
- Enabling the service by creating the symlink. This is what update-rc.d does in
sysvinit.

A better approach would be to concentrate on the second task, and create
runit-enabled versions of update-rc.d, invoke-rc.d etc. In Debian the default
behavior is to start up a daemon when its package is installed (on Void the
user needs to enable it manually), but this might not work well with runit. If
you have an initscript that is driven by ENABLED=1 in /etc/default/<package>,
then if this flag is set to 0, the script exits and that's it. With runit,
when the symlink is created the service is already enabled in the sense that
runsv will try to run it continuously. So this trigger of cpsv that both
copies the service to /etc/sv and enables it should be rethought.

>Hmmm the situation is definitely not easy at the moment. The Devuan/
>Debian init diversity team is small. The Devuan developer team is also
>small.
>
>Best changes are in case you really offer to help and engage and maybe
>discuss your ideas on the Debian init diversity mailing list first.

Alright, I understand. I know it's not easy to swim against the current.

Best Regards,
Lehel