Re: runit-void: split package into main package and init controls

[heliocat <heliocat@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

New comment by heliocat on void-packages repository

https://github.com/void-linux/void-packages/pull/29115#issuecomment-788467977

Comment:
@ahesford, thanks for the reply. From a high-level standpoint a decent chunk of void-runit seems generic enough to be reused, only `2`, `crtlaltdel`, `halt.*`, `runsvdir`, `services`, and `shutdown*` directly depend on runit. `3` relies on runit by default but the calls to `sv` can be elided in rc.conf pretty easily. Obviously the calling semantics are rooted in runit conventions but that's it. In a larger overhaul or future follow-on work if something like this was embraced I could see making an argument for moving a lot of the contents of void-runit into base-files (core-services, vlogger, zzz,  etc) though it would probably make sense to make base-files a distinct package as opposed to part of void-packages. 

Something that I've been trying hard to avoid is accidentally making a fork of the distribution. I know that there are other people using Void as a baseline for various supervision-based init alternatives and it's a management and maintenance overhead for each person to backport upstream changes into their bespoke derivatives. My goal with this PR (in whatever form it finally ends up taking) is to add just enough flexibility into the core distribution to facilitate letting people do these experiments and system drifts without having to fork or hold core parts of the distribution. That isn't to say it'll work perfectly without a shim, but managing a compatibility shim is a lot easier when you aren't fighting the package manager. Also, I'm not advocating that Void take on any support burden for people using these knobs, just just there isn't an expectation of support if someone uses alternatives to switch in a magical rust implementation of awk, and in making these knobs I've been trying to make sure to not add additional management overhead for the distro maintainers or the core system.

If there's a place with the documented pitfalls of alternatives and virtual packages that would be great. I did just find void-linux/xbps#318 which seems mildly terrifying but I am definitely interested in seeing what else there is. At the end of the day I'd like to get this merged, but I'd like to get it merged in the best format I can, and one that impacts the core Void maintainers the least.