About MC for managing the image

[Daniel Vainsencher]

I'm creating an MCConfiguration2 class, so we can play with them in 
parallel.

 > Yes, you can do that. But what that means is more work since many
 > implicit updates that work because of the implicit order will
 > no longer  work.
To my current understanding the only implicit updates that will affected 
are ones where having distinct configurations would probably be better 
documentation of what is going on anyway, and that might or might not 
turn out to be less than you think.

 > This would be a net loss.
I don't know yet.

Daniel

Andreas Raab wrote:
> Hi -
> 
> Daniel Vainsencher wrote:
> 
>> However to me the fact that they specify a load order, instead of 
>> loading all those versions simultaneously, looks like a bug. The way 
>> I've been thinking about ordering issues is that if you need to 
>> specify an order because of reference dependencies, that's what 
>> simultaneous loading is for. If you need to specify an order for 
>> bootstrapping reasons, then you should have a sequence of 
>> configurations that each specify a step that works from the previous 
>> step, and allow those steps to define the necessary orderings of changes.
> 
> 
  Also, I do not understand what you guys
> refer to when you talk about "simultaneous" loading. What exactly does 
> that mean? One of the advantages of packages is that you have control 
> over granularity and that extends to loading them - the fact that you 
> *can* specify the order in which packages get loaded is an advantage in 
> my eyes (I certainly have used it often enough).
> 
>> So unless there's another reason for the total order, or a problem 
>> with one of the above, it seems we can avoid specifying and 
>> maintaining a load order, and also be able to load circularly 
>> dependent packages.
> 
> 
> The need to "specify and maintain a load order" seems strikingly similar 
> to "specify and maintain dependencies" ;-) But in any case, this is all 
> about the cost-benefit ratio. As long as dependencies don't get into the 
> way (so far they have) and offer actual advantages (so far they haven't) 
> I'm all ears. Let's just not be too quick throwing the configurations 
> out with the bath water - I'm not convinced yet that dependencies will 
> offer any benefits over configurations; simply because I think having a 
> well-defined (and accessible) load-order is vastly advantaguous to 
> trying to figure out how to load what and deal with the effects when 
> things go wrong. But we'll see and I'm certainly willing to give it a shot.
> 
>> So I'm proposing to have MCConfigs to use simu-load for users and 
>> simu-merge developers, and ignore any specified order. Avi and have 
>> sketched the needed changes out, I'll work on it soon.
> 
> 
> Again, please explain "simu-load" and "simu-merge". This discussion is 
> the first I ever heard about it and I just don't know what this means 
> exactly.
> 
> But to summarize: Am I correct in understanding that you are proposing 
> to change loading configs in order to use dependencies to create 
> configurations? If not, I fail to see how this last paragraph relates to 
> dependencies ;-)
> 
> Cheers,
>   - Andreas
>