From Jan:
That's a more reasonable size than your first example. Although this ...Allowing the sysadmin to completely override the service. Unfortunately this also forces the sysadmin to override the service for every so little change,... then begs the question: what's the advantage of having the ${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort does this save the admin over creating their own my_seatd service and disabling the one you provide? (Honest question, I don't fully grok s6.)
It does not have anything to do with s6 itself,it just allows original service scripts to sit at /usr/lib/s6-rc/{user,system}/src/service
and be recklessly updated by the package manager.Installing them initially to /etc/s6-rc/{user,system}/src/service and editing them in place
will not allow that. This is in part mitigated by:
But this introduces needless complexity just to save one line in every script.I am not sure if I understand correctly, the files under /usr/share/s6-rc/{user,system} are to be there only as a reference, not to be edited. Are you trying to say that the non-edited files should be symlinked rather than copied?I was indeed trying to say that. But on second thought: you should do whatever Gentoo usually does with such configuration files. Consistency trumps any minor advantages any particular approach might have.
The best would probably be for s6-rc-compile to allow for multiple definitions of a service,
letting later definitions override earlier ones, e.g.
s6-rc-compile ${OUTPUT_DB} ${SOURCE_1} ${SOURCE_2}
where seatd-srv in ${SOURCE_2} overrides seatd-srv in ${SOURCE_1}.
Would this be realizable Laurent?
Regards,
Paul
OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
