On 01/21/2015 06:09 PM, Wayne Marshall wrote:
4) in general, folks here are letting their panties get far too twisted
with the dependency problem. Actual material dependencies are
relatively few and can be easily (and best) accomodated directly in the
runscript of the dependent service. See the perpok(8) utility for a
way to handle dependencies that is suitable in practice for most all
installations:
I'd like to second this notion, as well.
The core issue, the way I interpret it, is that "dependencies" within
the context of services
and of libraries, are quite different. A library will at the least need
a stub that exports the
expected symbols to resolve a dependency. In contrast, at its most
primitive, services simply
need to be started in an order that descendingly satisfies the
dependency chain.
Thus, if a dependency system is too weak, then it becomes scantly more
than an idealized way
of expressing startup ordering, one with a little less administrator
effort, but making the
feature conceptually uninteresting and of little use. But if it is too
powerful, then it incurs
a maintenance and complexity cost, ends up requiring complicated
scheduling semantics,
and thus the whole design starts to suffer.
I'm not sure what effective and worthwhile ways there are to express
service *relationships*,
however, or what that would exactly entail. I think service conflicts
and service bindings might
be flimsy to express without a formal system, though I don't think it's
anything that pre-start
conditional checks and finish checks can't emulate, perhaps less elegantly?
