Hi Stephen

>>In a notion of verified working sets with specific packages, 
>>something like this will happen: package A needs C-1.5 and package B 
>>needs C-2.0. You want to have A and B in your image. Now your are 
>>stuck. Perhaps both would have been happy with C>1.0 .

>Config
>    PackageA 1.0
>       for PackageC use PackageC 1.5
> 
>Config
>    PackageB 1.0
>       for PackageC use PackageC 2.0
>
>Now, you would add a third config that would deal with the version 
>skew: 
>
>Config
>    PackageA 1.0
>       for PackageC use PackageC 2.0
>    PackageB 1.0
>       for PackageC use PackageC 2.0
>    PackageC 2.0

The problem is that you are not the author of A and B. You can't find 
out that easy if A and B are satisfied with a larger range of versions 
of C too. 

Second problem: Everyone who wants to load A and B must write your 
added config, it is more efficient to do this only once. 

With this 'added config' you are only doing something afterwards ( 
perhaps multiple times in perhaps different scenarios ) which could be 
done beforehand once by the one who could do it best - the author of a 
package. 

>Loading this config would load PackageA 1.0, PackageB 1.0, and 
>PackageC 2.0.  You'd need to test to make sure that PackageA 1.0 
>really does work with PackageC 2.0 (and indeed whether or not 
>PackageA and PackageB can live and work together in the same image)...
>that's where good SUnit tests come in handy.

The SUnit tests can not replace the knowledge of the authors, and 
again this work may have to be done many times instead of once. 

Of course I accept Göran's argument that a new up coming version may 
break a 'wide range specification' like version > x. But I think it is 
an advantage that a linear version dimension allows for ranges AND for 
specific versions. The ranges should be handled with care by the 
authors. 

regards,
Martin