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 controlover 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
OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
