About MC for managing the image

[Avi Bryant]

On Sep 18, 2005, at 12:53 PM, Andreas Raab wrote:
>>
>> I do think that using a Squeak package with dependencies, or   
>> alternatively just changing a Configuration to have a load  
>> strategy  more like a package with dependencies, would be a good  
>> idea.  When I  recently tried updating a 3.9a image through a few  
>> configuration  steps, it was bad enough that it took as long as it  
>> did, but it was  awful that it stopped to ask me about loading  
>> over a modified package  many times during the process - so I  
>> couldn't just walk away.  This  wouldn't happen if MC's multi- 
>> package-load mechanism were used  instead of explicit ordering.   
>> It would also mean you wouldn't  (usually) have to think about  
>> package ordering yourself.  So it  should speed up the process for  
>> everyone.
>>
>
> Please say more about this, since it's been a while that I have  
> used dependencies in MC at all. About load strategies: I don't know  
> what strategy MC uses but unless it gets this right every single  
> time (which I doubt) having configurations is vastly advantageous.  
> Usually, I have a "master configuration" (for a project like Tweak)  
> which lists the fifty or so packages in what I consider "load  
> order", e.g., a unique order for loading the packages that includes  
> eventual dependencies. If I post a new configuration I simply  
> "update" the old oonfiguration from either image or packages and  
> post it. It's a very simple process but if there's any need I can  
> re-order the packages for that specific post.

Let's say I have two packages, A and B.  I have a new configuration  
in which these two packages have exchanged methods: one method from A  
has moved to B, and one method from B has moved to A.  I try to load  
that configuration.  Either load order is equivalent, but let's say  
that we've specified that the order is A, B.

What happens is this: first A is loaded, taking one method from B and  
losing one method itself.  Because it took a method from B, B is now  
marked as being modified.  Next, B is loaded, but it has a modified  
flag, and so the user is asked whether it's ok to ignore those  
modifications.  This is confusing, since the user never has modified  
B.  It's also irritating because the load can't proceed unsupervised.

Ok, now a more complicated scenario: A has added a Foo class and a  
BarSub class.  B has added a FooSub class and a Bar class.  FooSub is  
a subclass of Foo, and BarSub is a subclass of Bar.  This is  
admittedly contrived, and arguably bad design, but there's no  
sequential load order that will work for these two packages.

Both of these cases are solved by simply asking MC to load or merge  
the two packages together, rather than asking it to load them  
sequentially.  The load strategy it uses is very simple: a superclass  
always needs to be loaded before its subclasses, and a class always  
needs to be loaded before its methods.  Additions are always done  
before removals, and removals are done with the inverse rules (first  
remove methods, then classes, then superclasses).

What you don't get to do in that case is specify anything about the  
load order yourself.  I think the cases where specifying this is  
necessary are going to be very rare, but certainly they will happen.   
That's what the update stream is useful for: simply put two  
configurations in (one of them, maybe, with only a single package) to  
ensure that loads happen in the correct sequence.  This should only  
be needed for delicate migrations, I don't think it should ever be  
needed for every time a group of packages is loaded together.

Avi