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:
>> 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.
>
But this introduces needless complexity just to save one line in every
script.
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
Received on Thu Sep 19 2024 - 21:07:06 CEST