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