Supporting multiple init systems in Ravenports

[kraileth]

As a first step towards multiple init system support, I propose to make rvn aware of init related subpackages. Here's the list of init systems that I think make sense reserving the names for, so we're likely done with it forever (unless somebody makes a really good case for something even more exotic):

• bsdrcd
• dinit
• epoch
• launchd
• openrc
• runit
• s6
• smf
• systemd
• sysvinit

I would suggest adding a new rvn.conf option. While the following will skip ~dev subpackages unless explicitly requested,

SKIP_DEV_SUBPKG: true

we could have something like this to handle init scripts:

SERVICE_MGMT: auto

Valid values would be the ones listed above as well as 'none' and 'auto'. The latter could default to installing 'bsdrcd' scripts on *BSD, 'systemd' unit files on Linux/glibc, 'runit' files on Linux/musl and 'smf' definitions on solaris. Other options can be configured manually by the user if desired.

I can think of two variants to organize this. It could either be done by

1. having a subpackage of the same name as in the list above for every program that contains a daemon
2. having a single ~init subpackage which requires the porter to use keywords like @bsdrcd, @systemd and such in the respective manifest

Option 1 is probably simpler but potentially more messy (if the community grows and we end up supporting several init systems) while option 2 is a tiny bit more work for the porter but much cleaner.

[jrmarino]

other than being perceived as "messy", what's the issue with just installing rc.d scripts and systemd scripts and any other supported init script? Each has it's own directory I think.

for practical considerations, there's no way we can provide adequate support to 10+ service implementations.

and I think this all hinges on a dedicated person caring for their platform. we can't expect BSD people to adequately support systemd and vice versa.

[jrmarino]

i don't understand the reference to the "dev" subpackage. service scripts are not typically installed by dev subpackage.

[jrmarino]

we could add system specific equivalents of RC_SUBR
for example, systemd manifests only packaged on linux and smf manifests only packaged on solaris-based distros

[kraileth]

I mentioned ~dev simply as an example of the package manager's configuration being responsible for what people get. This could be done for init systems, too. I also don't expect to ever support everything on that list - the question is simply which one(s) people who eventually step up and agree to maintain them prefer. Real world example: I wouldn't want to have to deal with SysV init, but there's a young (started 2021) distribution called Peropsis which uses that init system. They are looking for a package manager and are considering Pkgsrc. If (and that's purely hypothetical, I haven't approached them or something) for example they were to adapt RP and maintain SysV init scripts - hey why not?

I've considered extending RC_SUBR, too, but I think that's more inflexible compared to my suggestion. If somebody volunteers to maintain init scripts for one of the more exotic ones, all they should ideally have to do is putting them in the respective ports' files directory, changing the specification to copy them into the right place inside the stage directory and tag them with a keyword in the manifest. That way they would get packaged but ignored by rvn on most systems except those specifically configured to install them.

You approach to decide on what to package at build time would of course also work. However that would mean that people in need of a non-standard init system would have to roll their own package sets when all that's different are a bunch of text files. Really systemd is the only problematic one that needs to modify compile-time options for ports. For all the rest it's just additional optional files. I'd very much prefer allowing for several of them, at least in theory. This kind of flexibility is one of the great benefits of RP after all.