proper support for multiple init.d

[navi-desu]

it'd make it easier to upstream services by having a script directory under /usr/libexec/rc to which packages could install to, as well as freeing /etc to be configuration only.

for that, we need to improve configuration loading and dependency resolution. to note that, those issues already affect current installs, as /usr/local/etc, and /usr/pkg/etc under netbsd, (and /usr/etc under linux apparently?) are looked up for services, but rarely things seem to use them.

configuration loading at the moment is based on the path to the init.d, so "${RC_SERVICE%/*}/../conf.d". instead, we should loop every possible script dir, and either load the first conf.d/$RC_SVCNAME we find, or all of them.

init.d logic already does that, loading the first init.d script found, but i argue that configs should overlay while init.d should overwrite

dependency resolution as is, is semi-broken when cross directory init.d are in use, due to the fact that we use shell expansion and thus can only chdir to one directory before matching after * or similar.

we could instead disable shell expansion in gendepends.sh, and instead do such resolution in c, for every script directory, chdir into it, then match wordexpr with WRDE_APPEND to build the actual list

[JustSoup312]

Would it make sense to build this into a meson configuration option (e.g. --initdir and --confdir) and allow upstreams to configure which initdir and confdir they want to use at buildtime? Potentially /etc/init.d/ can be kept as a fallback / override directory that is searched before the provided directory. This wouldn't solve the looping over directories, but it would probably allow dropping per-OS code on directory placement.

[navi-desu]

i have a local wip branch for this, we'll check RC_PATH as absolute : separated paths, if that's unset, we'll have the following defaults:

/etc/rc
/etc # compat
$XDG_CONFIG_DIRS
$localpkgdir/rc
$libexecdir/rc

localpkgdir and libexec are compile time options, localpkgdir is /usr/local or /usr/pkg depending on platform

user services have the very same structure, with a /user suffix, and $XDG_CONFIG_HOME goes on top of it all

[JustSoup312]

Sounds good to me, but would that imply the renaming of init.d to rc?

[navi-desu]

nope, inside rc/ we have both init.d and conf.d

[JustSoup312]

Oh, that's really nice. Always bugged me that init.d and conf.d were just sitting in the raw directory and not in something logically segmenting what it is. (init.d and conf.d are vary vague directory names without context.) Is there any plan to have UAPI config spec style loading (e.g. allowing sysadmins to override package manager defaults without messing with package-manager installed files)? I've found such config style to be very robust and intuitive, but just requires a little initial effort to get moving. I bring this up because it shouldn't be too much extra work on top of supporting multiple init.d. Doing it after a design is merged could easily cause annoying pedantic edits, but that is if you like the idea. :)

[navi-desu]

openrc has separation of mechanism and policy, init.d is mechanism, 'what to do', and conf.d is policy 'how to do it'

so my current idea is, for each RC_PATH entry, we take the first init.d/$service as the canonical service, but source all conf.d/$service files found, if any

since conf.d files are shell variables, sourcing them in reverse order gives us somewhat inherent "overriding"

i didn't know "uapi config" was a spec, but what we designed is basically the same thing i think, except we don't have "drop-in" '.d' directories -- because init scripts don't have a suffix, because both foo and foo.d are valid service names

should drop-ins be really necessary, we could employ heuristics, but i'd rather not if possible

[JustSoup312]

Seems like a valid strategy. No reason to add drop-in as well since services are a bit more complex than a regular program. Is there a branch / MR that I can help contribute to to help out?

[navi-desu]

Is there a branch / MR that I can help contribute to to help out?

i've implemented most of it today, tomorrow i'll clean the impl a bit, add docs, then put a MR up

if you could test it out then, that'd help tons

[navi-desu]

took longer than i wanted, but it's up: #942

i still didn't fully test it, and there's a few questions up that feedback on would be lovely (plus overall feedback on the design and implementation would be great)