introduce RC_PATH and dynamic path resolution #942
Conversation
rc_dirs.set will become a flag for the cleanup atexit function, so it can't be used to determine if alternative paths themselves are set
navi-desu
force-pushed
the
paths
branch
2 times, most recently
from
624d4bd to
317645b
Compare
the path lookup goes as follows: $XDG_CONFIG_DIRS/rc /etc/rc /etc /usr/local/etc/rc /usr/local/etc /usr/libexec/rc for user services, $XDG_CONFIG_HOME/rc is added at the top, and /user is append to all other paths additionally, RC_PATH is read from the environment, if it is set, it is split at every semi-colon and used in place of any default path /etc and /usr/local/etc are provided as compatibility and using the /rc variants is prefered /usr/libexec/rc is a new location, meant for system packages to install init.d to, as many distros would like to have all system packages install to /usr alone and not touch /etc Closes: #823
generalizing the logic via RC_PATH makes it more flexible, and allows better usage of multiple unique init directories we load the config directories in reverse order so that "overriding" works as intended, i.e., /etc takes preference over /usr this also makes config directories additive, while init directories are completely replace each other, config directories are combine, meaning to change one setting, only that setting needs to be presented in a higher-priority conf.d
|
Tested on postmarketOS edge (2025-11-05) and verified working. A few services failed but I am pretty sure that is just because I hacked together the Alpine patches on top of this update and it didn't like that, but service loading worked, so that's good. My thoughts:
I say probably yes. If it simplifies logic, then no harm.
/openrc makes the most sense to me. Directory names should be descriptive of what they are used by, and as you said /rc can be taken by other service managers, which would be a conflict for no reason.
I would say overlay so a user can modify single settings of a service without duplicating the service config that might be put there by system vendors.
If it is for both init.d and conf.d, then
I don't see why
In this case, data is anything that can be architecture-specific. Configuration is anything that can not be architecture-specific. Thus, services are usually data and configs can be data. |
|
thanks for testing it
we'd have to keep .config/rc as compat, then later move $libexec/rc -> $libexec/openrc, and though don't think other service managers would take '/rc', but a problem is, e.g. the 'rc' shell /openrc looks kinda ugly to me compared to /rc, but i guess it'll have to do :(
user-wide installs that go, e.g.,
i'm not sure that matches? e.g. manpages count as "data", and they're not arch-specific i usually see data as "read-only content to be processed/displayed", and config as "read-write files that change behaviour", and executable scripts like our init scripts are weird to me bc they don't quite feel like either, bleh |
Ohhh that makes sense. Yeah, the rc shell could get mixed up.
I guess that makes sense, but it still feels weird. Guess no harm in including it if there is precedent.
In the context of the Linux filesystem, stuff in |
|
another thing to consider about '/rc' vs '/openrc', is that we also already use rc.h and librc.so |
|
On /rc vs /openrc. I don't think it matters currently since it would involve moving other named pieces over to openrc instead of just rc if decided upon. Perhaps it makes sense to get this in first and then decide upon a default name without introducing scope-creep accidentally. |
|
that's... a good point, actually (i need to stop doing this thing where i stall doing things over decisions like that) /rc vs /openrc aside, we can merge this today, i'll add the DATA dirs to the path, and we merge |
|
No worries! I used to be the same way but pmOS taught me that if you try to get everything right instantly, it'll never get merged ;) |
a few questions still undecided:
--user) includeXDG_CONFIG_DIRS? so far i said "yes" because it simplifies logic¹RC_PATHorRC_INIT_PATH?XDG_DATA_HOMEandXDG_DATA_DIRSto the system path, should we do so as well? unsure if init.d counts as "data" or "config", or if that distinction even matters hereone goal with this patch set, is to eventually deprecate RC_USER_SERVICES, as nothing should really special-case it over doing proper "permission" checks
taking RC_PATH and RC_SVCDIR from the environment makes openrc's core logic more flexible, while removing special casing, and in doing so we redefine
rc_set_user()as simply "use the default RC_PATH and RC_SVCDIR for user services"this will allow us to later on remove all instances of
if (rc_yesno(getenv("RC_USER_SERVICES")) rc_set_user();we can't go that far yet due to runlevels and sysconfdir, but those i'm working on
i've yet to do a full non-superficial boot test with this branch, will do so over the next week
also the code is using strchrnul when parsing for convenience, it is not posix, but it's implemented by the bsds and musl. we could likely replace it without much difficulty, however.
1: systemd has casing for SYSTEMD_UNIT_PATH, where if it ends on an empty entry, aka,
:, it'll prepend the listed unit path to the default path, instead of replacing itby having XDG_CONFIG_DIRS be prepended by default, we avoid having to do such logic, and it makes the parsing code itself a lot more streamlined
should we not want to add XDG_CONFIG_DIRS to the system init directory path, we can instead incorporate the same special semantic as systemd