Martin Wirblat wrote:

>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.
>

Most of the time, neither can the author of A or B since they are not 
necessarily the authors of C.

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

It's only necessary to write the config if your config tools force you 
to write it.  A configuration can be created by simply "snapshotting" 
the packages that you have loaded in a given image.

Goran also has a plan for meta-information that will allow a package 
author to specify a level of compatibility (or interface stability to be 
more precise) between multiple package versions...this meta information 
could be used to do quasi intelligent pre-req substitutions...for 
example, if I try to load the default Config for PackageA (which 
specifies PackageC 1.5), but I already have PackageC 2.0 loaded, an 
intelligent installer would ask you if you'd like to use PackageC 2.0 to 
satisfy the pre-requisite...it would also communicate to you what the 
author of PackageC thinks the level of compatibility is between PackageC 
1.5 and PackageC 2.0...that may (or may not) aid you in your decision to 
use PackageC 2.0.

Once you have loaded PackageA 1.0 and PackageC 2.0, making a config for 
that is as easy as saying "make a config for that" since you have all 
the necessary information loaded in your image.  Similarly, if you 
wanted a config map that included PackageA and PackageB...you would say 
"make a config for PackageA and PackageB based on what's currently 
loaded in my image".

>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. 
>

No it can't.  The author of a package has absolutely no way of knowing 
whether a prereq of "PackageC >1.0" will actually work...that is, unless 
they have the ability to see into the future.  ;)  Thus, such a pre-req 
specification is not only inaccurate, but it's also very problematic.

>>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. 
>

I don't see where anything has to be done "many times instead of 
once"...it's simply not the case.

- Stephen