Hi Guillermo! Long time no see 🙂
>1) Stores: 's6 repository init' and 's6 repository sync' create a
>"reference database" using s6-rc-compile, with the union of services
>defined in all stores linked in the repository, correct?
Correct.
A feature that exists in the current git (but not in s6-rc-0.6.0.0)
will allow service definition overrides: later stores can override
definitions from earlier stores.
> That means that
>all stores must present a coherent view of services; they can't be
>uncoordinated, or otherwise s6-rc-compile could fail while trying to make
>the reference database, right?
Correct.
> So, how is usage of two or more stores
>envisioned? s6-frontend's documentation mentions a scenario in which one of
>them is managed by the package manager of the distribution; what would
>additional stores (if any) be expected to contain?
The idea is that a local store could provide its own batch of
services, independent from the global store. Sysadmins could write
their own stuff there. The distribution could add some polish that
cannot be handled by service definitions packaged independently and
installed by the package manager.
I don't expect additional stores to contain a lot of stuff, but there
needs to be at least a place for the equivalent of /etc/rc.local.
With the override feature active, additional stores will also be
able to e.g. locally modify the behaviour of some distro-provided
services.
I fear this may be a bit brittle, but the onus is on the distro to
have a consistent view of all the services it packages, and for the
additional stores, the onus is on the local admin to avoid breaking
things. It's not that much different from saying "here's your own
/etc/init.d that will mix with the official one, use at your own risk".
If good usage patterns emerge from practice, I'll be glad to document
and encourage them. If practice shows that some things are awkward
and s6-rc's behaviour needs tweaking, I'm obviously committed to making
the necessary changes.
>2) Sets and prescriptions: so, an s6-rc compiled database made from a set
>that has no masked services would be equivalent to the reference database,
>plus one automatically added bundle (the one that 's6 system boot' starts)?
Correct.
>3) Set inconsistencies I: if service A's prescription is "active", A
>depends on service B, and B's prescription is "usable", does 's6 set check'
>report that as an inconsistency?
Yes, it should.
> If service A's prescription is "usable", A
>depends on service B, and B's prescription is "active", does 's6 set check'
>report that as an inconsistency?
No, unlike the previous one, that configuration is valid.
B can be up while A is down, and that's what will happen if you boot
on this set: B will be part of the default bundle and started at boot,
whereas A won't.
>4) Set inconsistencies II: does 's6 set commit' fail if the commited set
>has unfixed inconsistencies?
Yes, it will fail (it performs a check before the commit itself). And
the error message should show you a list of inconsistencies, just like
with "s6 set check".
--
Laurent
Received on Fri Feb 06 2026 - 04:58:08 CET