On 29/09/2015 04:46, Casper Ti. Vector wrote:
   Nevertheless, I think it can be helpful to also support "opportunist"
   dependencies: if said service is not enabled, it is silently ignored;
   if said service is enabled, the dependency on it is considered in the
   dependency resolution process.

 As you subsequently wrote, this can be left out of s6-rc. An "opportunist"
dependency is not a real dependency, since the service can start without it;
if you want to include it, a preprocessor for source directories is the
exact right thing to use.


* Online `OR'/virtual dependencies:
   (...)  For example, with a laptop, it's common and useful to have
   `eth0' and `wlan0' both providing network access, and a
   network-dependent service can start when either is up.

 That kind of dependency is still infrequent compared to "normal"
dependencies; I don't think it's unreasonable to maintain a set of
compiled databases to address that case. The size of the set may
grow exponentially, but if it becomes larger than 4 or 8 databases,
I tend to think it's an abuse of virtual dependencies; I can be
convinced otherwise with a real-world example that cannot be solved
another way.

 Having several compiled databases and switching between them with
s6-rc-update is normal procedure. I worked on s6-rc-update for a long
time to make sure that this procedure would be as painless as possible,
even if it has to be done on a semi-regular basis. Switching between
eth0 and wlan0 is a typical case of this, and as a matter of fact,
it's *exactly* what I'm doing on my home router. :)

--
 Laurent

Reply via email to