Paul Sopka schrob:
> - The sysadmin or the user can copy a skeleton from
> /etc/s6-rc/skel/{config,src} (which is populated by the package
> manager with configs and initial bundles) to ${HOME}/.config/s6-rc/,
> this folder shall be used for configuration and custom user services.

A skeleton is not config data, and should thus be in /usr/
Possibly /usr/.../examples/...

> - The package manager puts service source directories and an initial
> set of bundles for system services to
> /etc/s6-rc/system/src/{services,bundles}.
> 
> - The package manager puts service source directories and an initial
> set of bundles for both user and system services to
> /usr/share/s6-rc/{user,system} as a reference of the defaults.

If you put defaults in /usr, then prefer symlinking them into /etc,
rather than creating a copy. That'll automatically handle changing
defaults, and make it obvious what is locally customized.


> - The idea of config files is completely dropped and the "editing the
> config" part is shifted to "editing the run-script"
> [...]
> Do you suggest any alterations or even a completely different approach?

Void has a nice idiom in their run scripts:

| #!/bin/sh
| exec 2>&1
| [ -r conf ] && . ./conf
| exec acpid -f ${OPTS:=-l}

That achieves 3 things:
1) It works out of the box (without a conf file).
2) The user can create a conf file containing
        OPTS='-l -d -S'
   to customize the daemon options.
3) The user can create a conf file containing
        if [ $((`date +%s` % 100)) -eq 0 ] ; then poweroff ; fi
        exec /usr/local/bin/notreallyacpid --foo
   to completely¹ override the run file.

Note how the KEY=value pair in 2) is actually shell, hopefully
eliminating any worries about config file format.

HTH,
    Jan

¹)
The "exec 2>&1" is an artifact of how runit does logging, and should
always be done. Hence it comes before the conf entry point. If there was
a valid use for stderr, lines 2 and 3 could be switched, of course.