Re[2]: s6-frontend & new s6-rc questions

>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