> I think there's a misunderstanding here, I'll try again:
> What I proposed is putting the service definitions into /usr, never copy
> or link them to /etc, never modify them (except by package updates), and
> let s6 execute them directly from there.
>
> If the local admin wants something other than the service as you ship
> it, they create a completely new, independent local service and disable
> the one shipped by you.
>
> Thus you can update the definitions in /usr as you see fit, and the
> admin can override things as they see fit. No machinery needed inside
> the actual run scripts.
I do not think that providing only this option this is a good idea,
since names are unique and dependencies are declared in the dependent
service.
Consider the example of "seatd-srv":
The sysadmin disables it and creates "seatd-new-srv",
now he has to create a "${SERVICE}-new-srv" for every "${SERVICE}-srv"
depending on "seatd-srv"
to adjust their dependencies, do the same for every
"${SERVICE}-new-srv", ...
Of course, this can easily be solved by only ever depending on bundles,
thus, one creates "seatd-new-srv" adds it to the bundle
"seat-management"(everyone depends on),
removes "seatd-srv" from "seat-management" and has exactly what you
envisioned.
Thus, a policy of "only ever depend on a bundle", which I already
employ, is needed.
Anyway, I am not sure if all if this additionally requirement is really
worth saving one line per service script.
A point for your approach is, of course, that the user gains full control
over the service he changed, as he is able to change the logging
behavior, dependencies, ...
That however, requires way more insight into the entire service system,
s6 and s6-rc
as opposed to "read the script, understand the script, adapt the script,
put it in the right place".
Regards,
Paul
Received on Fri Sep 20 2024 - 12:19:34 CEST