Martin Wirblat wrote:

>Hi Göran,
>
>  
>
>>"updated every time a new version of a prereq arrives" ??
>>
>>Personally i want the dependency system to describe "verified working
>>configurations" and nothing more. Rules like "any version later than 
>>x" are IMHO not so good.
>>    
>>
>
>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 . 
>
>But if you want to, you are able to describe a specific package with 
>name+version too. 
>  
>

You're missing Göran's point.  The problem you describe is *exactly* why 
what Göran proposes is the best way.  Using your example, prerequisites 
in package A and B would be specified as follows:

PackageA
    requires PackageC

PackageB
    requires PackageC

Both packages would also have the following configurations that match 
exactly the configuration used to develop PackageA and PackageB:

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

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.

It's important to note that the "requires" clause in my notation is 
simply a name...the requirement is not tied to an specific package or 
package name...it is only a name.  It's the configuration that 
determines what package and version will actually get used to satisfy 
the "requires" clause.

- Stephen