Ned Konz <ned at squeakland.org> wrote:
> I was trying to get together a harvesting image.
> 
> Start with a 3.2 image.
> 
> Try to update it to 3.7a-5816 from a (local) updates server.
> 
> at 5402, choose to go to Full
> Which eventually loads SqueakMap
> which prompts for upgrading SqueakMap to 2.0
> on prompt for upgrading SqueakMap to 2.0 choose yes.
> Opens a package loader but then aborts the update after opening the 
> PackageLoader.
> 
> Does not mark the image as 5402; stays at 5401.

5402 triggers a #loadUpdates if you choose to go to Full.
So SMSqueakMap contacts the server and decides to start the bootstrap
code and thus installs SM2 and then does the
terminate-this-process-trick you also did in one update recently.

That is the reason it probably misses to mark it as 5402.

> resume updates.
> 
> Get a "that name is already used" on 5402.

I assume because of the terminate-process-trick above. What did you guys
do with the other update recently with the same issue?

> in 5527, get an Error: 'password is already defined in a subclass of 
> SMObject'.
> say to proceed.

Oh. Ah. Hehe. 5527 is version 1.08 of the old SM1 code. But... the
bootstrap above (5401) caused SM2 to be loaded so 5527 overwrites SM2
with old code. Not good. That explains the instvar problem too.

So.. these are the funny problems we get when the updates in the stream
aren't deterministic! :)

Hmmm. 5527 should probably be... removed. And 5528. 5527 has a
postscript with some migration code - perhaps we should keep that
though. My brain is melting... ;)

> In 5727, when SmaCC is being updated from SM, get an error because there is no 
> SMSqueakMap class any more!
> 
> Looks like 5708/5709 did not deal with already having SM2 in the image.
> 
> 5708 blew the category away, and it did not get fully reloaded.

Yes, something is strange somewhere in there. There was some weird thing
happening earlier that I never really got a hang of - it seemed that
IIRC:
	SMSqueakMap class superclass subclasses includes: SMSqueakMap class
..evaluated to false.

Not sure if that has anything to do with this. Frankly - if anyone can
debug this and understand what goes wrong I would appreciate it.

Finally - I guess we could augment 5708 to not waste SM if SMPackage is
available.

regards, Göran