[RFC] Seperate init scripts into different package to support different inits officially

[ghost]

Currently Void Linux only offers Runit init. I want VoidLinux to offer other Init systems too. I am specifically eyeing for s6 .

Currently VoidLinux packages init scripts into package itself. But,i want Voidlinux to pack them into seperate package like what Artix Linux does.

To be more specific, if packagename is package, i want packagename-openrc , packagename-runit , packagename-s6 too. device using runit would install packagename-runit package and device using s6 would install packagename-s6 package. Thus,we can support different inits officially without any hacks.

You would rebut this method by saying that when a package is installed, init scripts must also be installed automatically. I have solution for that too. a package packagename would depend on packagename-init . there would be 3 repositories void-openrc , void-runit , void-s6 . if device is using runit,then void-runit repository would be added. if device is using s6 , then void-s6 repository would be added. packagename-init package in void-runit would contain runit scripts while packagename-init in void-s6 would contain s6 scripts.

At last, i would like to ask you not to reply "All devs use runit,so there is no interest in other inits".I am sure there are many who would like to support other inits. I love void very much and would love void to support other inits officially as well.

[ericonr]

IMO Artix's service split is unnecessary and way too complicated. If we want to support multiple inits at the service level, most services already support runit and s6 without changes, and if we ever wanted to support OpenRC (despite giving up on supervision seeming to me like an extremely bad idea overall, so I don't think anyone will), the services could still go in the same package. Users can just take the few more bytes they occupy or add the directories to noextract=.

There are people looking into reusing the void-runit framework to enable s6 while still taking advantage of the current infrastructure, but it only touches the void-runit package and adjacent ones, not every single package.

Void is primarily a runit distro, and we want the maintenance burden (and even mental load on users) to be optimized for that.