So, for example, say store in /usr/share/s6-frontend/s6-rc/sources is managed by the distribution, and there's a second store in /home/guillermo/s6-rc-sources managed by me. The first one should be usable by itself (i. e. s6-rc-compile should be able to make the reference database if the repository only used that store), and the second one would have atomic services not present in the first one, that can depend on services in either of them. And for next s6-rc, also maybe overrides for services in the first one. Something like that?
Something like that, yes. It is more likely that the distribution would also have a /etc/s6-frontend/s6-rc/sources for stuff that it can't provide in packages, and that you would need both /usr/share/s6-frontend/s6-rc/sources and /etc/s6-frontend/s6-rc/sources in your storelist for it to be usable; but you could append /home/guillermo/s6-rc-sources to the storelist, have services in there that depend on the other stores, and that would work.
And why is that an inconsistency? The only difference is that A would be in the "default" bundle and B wouldn't, correct? But when 's6 system boot' starts the bundle, A starts because it is in the bundle contents, but B will start anyway because it is a dependency. This final machine state looks fine to me, unless there's an expectation that "usable" prescription should imply "down" state until an explicit 's6 live start'. Which I wouldn't assume from the prescription's chosen name (and don't remember reading in the documentation). B is "usable" and "used" in this case.
The prescriptions represent the exact state of the machine after a complete boot. The configuration would work, but it would not match the user's expectation that B should be down, so it is marked as invalid to make the user realize that B will be up. I don't want s6-rc to sneakily start services the user isn't aware of. You could argue that there should be a separate flag in the service state saying "not explicitly wanted, just currently up because of dependencies", and that might be a good thing, but the current s6-rc core does not support that. Maybe in a future version, but that would imply reworking deep things, so don't expect it in the short term.
So, given the answer to 3) it looks to me like 's6 set commit' forbids some configurations that don't seem to actually create problems.
Indeed, some configurations don't create problems, they just don't match user expectations and I think it's better for everything to be square and clear before committing.
...which makes me ask: does 's6-rc -da change' stop services not marked with "flag-essential" in their definitions, that are dependencies of essential services? Does s6-rc-compile fail or warn if that happens in the submitted set of services? Unless I'm misunderstanding the code, it looks like that they don't?
No, this is not handled by the s6-rc engine indeed. The configuration should never happen. I will add a check in s6-rc-compile at some point to forbid dependencies from an essential service to a non-essential one, and make "s6-rc-db check" fail as well. For now, it's on packagers to handle flag-essential carefully.
...which makes me ask: isn't GOLB_HIDEESSENTIALS set in s6-rc-0.6.0.0 for the wrong option (-D instead of -d), or am I misunderstanding the code?
The flag has two different uses. It is called "hide essentials" because it will hide them for "s6-rc list", but it is also used in "s6-rc stop" to mean "stop essentials anyway". Which is not great semantically, because in one case (s6-rc list) I want the default to be "not special treatment for essentials", and in the other (s6-rc stop) I want the default to be "special treatment". So in theory there should be two separate flags, maybe, but, meh. When you're just calling "s6-rc -Da" you don't realize the underlying implementation of -D over -d is semantically questionable ;)
Also does 's6 live install' fail if the current set never had a successful 's6 set commit'? There's no compiled database for the set before that, right?
It does fail, yes. That's why there's a --init option for the first installation: https://skarnet.org/software/s6-frontend/s6_live.html#install -- Laurent
