Stephen Pair <stephen at pairhome.net> wrote:
[BIG SNIP]
> I think you need to be careful that "load scripts" and "configs" are 
> sufficiently different animals that you're not just replicating 
> everything a config does in a load script.  For example, I will want to 
> simply select one or more configs and say "load them" without needing to 
> define a load script.

Sure.

> Conversely, when I do define a load script, I'll 
> simply want to identify one or more configs and perhaps packages to load 
> (together with an ordering of those things).  Will a config carry enough 

Yes.

> information (i.e. a load order) such that a load script could be created 
> on the fly for a config?  Perhaps you could elaborate on exactly how you 
> envision load scripts working.

Well, sure - we could give configs an ordering. Note though that the
resolution engine will probably not be able to follow all orderings. For
example if:

A1.0
   B1.1, C2.0
Z1.1
   C2.0, D1.0, B1.1

Ok, Mr Engine - give me A1.0 and Z1.1. And Mr Engine will be confused
about the ordering of C2.0 and B1.1.

> If package A has a config that specifies KomHttpServer 6.2, does that 
> also imply all pre-requisites of KomHttpServer 6.2?  If so, do you need 

Yes. Or rather at least one of the possible configs attached to
KomHttpServer6.2 must be fulfilled.
Which one to use is the problem for Mr Engine to figure out.

> to be explicit about which KomHttpServer 6.2 config you are talking 
> about when specifying the config for package A?

No, hopefully you let Mr Engine do his work.

>  Or, does a load script 
> do that?  For example, would the load script specify package A (and some 
> config), KomHttpServer 6.2 (and one of its configs)?

If you want to - of course. But shouldn't *need* to specify configs.
Again, trust Mr Engine! :)

> If that's the 
> case, then configs don't really specify a completely working assembly of 
> packages (i.e. certain configs of KomHttpServer 6.2 may not work with 
> package A's config).

Exactly! Tada. Mr Engine to the rescue. And this is where the
backwards-compat-level of package releases come into play. But I have
told you all about that 10 times already.

> It seems to me that your definition of a config may really just a 
> listing of immediate pre-requisites for a package.  Which, in 
> combination with load scripts and good load tools, might work.  Not sure 
> I would call these "configs" though.

Well, please give me a better name then! :-) "Verified immediate list of
prerequisite package releases"?

> - Stephen

regards, Göran