New comment by heliocat on void-packages repository

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

Comment:
> * That said, alternatives are more for programs that make sense to be installed at the same time (think of `vim` vs `neovim` for example, or nvidia vs mesa) and you need to choose the default one. For init systems, this doesn't make sense, at least for me.

I'd argue that alternatives is the only mechanism that allows for safe replacement of the shutdown handlers while still leaving a recovery path if something goes wrong. Specifically in the case of runit-void vs s6-linux-init, the runit-void `halt` program primarily serves as a wrapper around calling runit-init with the correct arguments whereas `s6-linux-init-hpr` (intended to be symlinked as halt/poweroff/reboot) primarily functions as a mechanism to signal the shutdown service. Both have a force option that bypasses any handling, which allows runit-void's halt to shut down a s6-linux-init system (and vice versa), but down that road lies sadness and dataloss so I'd prefer to avoid it if at all possible.

> * While I'm in favor of having the option to switch to other init systems, I'm strongly opposed to support more than one at a time. I disagree with @leahneukirchen, that alternatives bring any benefit when experimenting with alternatives to runit and instead just introduce more indirection.

> * for tinkering, `replaces=runit...` might be the better option here.

I'm inclined to agree with the dislike of having more than one init but short of a hefty realignment of package contents there is a problem with that solution and that perspective. Specifically, runit (the suite) is two things: a process supervisor and half an init system (primarily pid 1). Similarly, runit-void is all of the low-level initialization policy mechanisms for Void and half of an init system (primarily the shutdown part). The initial form of this PR separated the runit-void shutdown programs into a subpackage but as @st3r4g mentioned that breaks the rollback guarantee of having the official binaries present in some form, as well as forcing users to use the `-f` options to bypass clean shutdown and instead directly signalling the kernel.

Regardless of what handles system lifecycle duties replacing the runit package isn't an option. First, it doesn't solve the halt, poweroff, reboot, or shutdown name collisions. But more importantly there are several packages with runtime dependencies on `chpst`, `svlogd`, or `sv` (mostly in the form of privilege dropping via chpst or calling `sv check some_other_service`) and replacing runit would instantly break those run scripts.