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