Daniel Vainsencher wrote:
> No, I'm proposing this only for installers, and that only as halfway
> measure for all those relatively simple packages that you can't install
> only for lacking the proper service.
> 
> This is definitely NOT a proposed replacement to having configuration
> package types that encapsulate things like dependencies (though the idea
> of a reflective service that uses SM itself might be useful in other
> contexts too).
> 
> I personally don't think we should model dependencies directly. If
> Goran's view of configurations is "I assert that the RB 1.2 works with
> PackageInfo 3.4", then my proposal is the agnostic "Loading PackageInfo
> 3.4 and then RB 1.2 and then ... is good". 
> 
> This could obviously be used to make sure both dependencies and proper
> scaffolding is installed before any specific package.
> 
> This handles any depth dependencies in one configuration, and also
> allows composition of configurations to make packaging modular.
> 
> Does this seem reasonable?

Yes, I had somewhat forgotten that we were thinking of configurations 
and not of individual dependencies.  It seemed reasonable when Goran 
explained it to me at OOPSLA and still does... just that I'd forgotten :)

I was pretty sure you were only talking about installers, but I wanted 
to make sure.

Goran, configurations are associated with package *versions* I assume? 
So I can say in a configuration for Seaside, for example, that Seaside 
works with Comanche 5.0 and then any valid configuration for Comanche 
5.0 would meet that requirement?

Julian

-- 
julian at beta4.com
Beta4 Productions (http://www.beta4.com)