On Sat, Aug 22, 2015 at 08:12:40AM -0700, Eliot Miranda wrote:
> Hi David,
> 
> Sent from my iPhone
> 
> > On Aug 22, 2015, at 7:15 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > Currently we have the problem that an existing trunk image from prior
> > to the Squeak 4.6 release will lock up if the user does a normal
> > "update from server".  A knowledgeable user can work around this, as
> > with the script that Nicolas provides. But a year from now our tribal
> > knowledge is likely to dissipate, so I don't really like the idea of
> > having the original trunk update stream end in a frozen image.
> > 
> > I think I have come up with a way to have the update stream switch
> > automatically from trunk to squeak46 for existing images, see attached
> > change set. The idea is to add this class into a separate package
> > "Temp-update-strean-migration" in the trunk repository, and add that
> > package to the last update map that worked for V3 images (I think this
> > is update-eem.321.mcm, is that right?).  The package loads a class that
> > checks to see if the image needs to be switched from trunk to squeak46,
> > and changes the update preference accordingly.  It then removes itself
> > from the system.
> > 
> > Does this seem reasonable?
> 
> Oh yes!  Looks a v good idea.  The only thing I could think of was adding a preamble to trunk Kernel & System to have them error on non Sour.  But your proposal above is /much/ better.  
> 

This seemed like a good idea, but I tried it and unfortunately it does not
work. There are two problems with this approach:

1) The updater does not load the new (temporary) package, because it will
not load anything that does not already have a working copy in the image.
So just adding the new package to the update map did not cause it to be
loaded.

2) Changing the update preference is not sufficient to change an update
that is already in progress, because it will already have loaded the list
of updates that it expects to process (including the spur ones). So even
if #1 had worked, it still would not have prevented the update from proceeding,
which still would end in an error (32-bit image) or image freeze (64-bit
image).

So ... sorry for the noise. I will try to think of a better approach.

I will also delete Temp-update-stream-migration-dtl.1 from trunk and remove
the dependency for it that I had added to the update-topa.322.mcm configuration
map.

Back to the drawing board :-/

Dave