Send in an update with "SMSqueakMap default loadUpdates". 

Daniel

Doug Way <dway at riskmetrics.com> wrote:
> 
> >>> SMSqueakMap default installedPackagesDictionary removeKey:
> >>> (SMSqueakMap default cardWithName: 'SARInstaller for 3.4') id
> >>
> >> This seems to work.  Assuming this is reasonably safe, maybe we should
> >
> > Should be safe. There are no other places (Except for the ChangeLog of
> > course! But we can't do much about that - replaying changes will get
> > this back, as would the #recreateYaddayadda method) with this state.
> 
> Oops, well it turns out this doesn't work in a fresh image which hasn't 
> had a PackageLoader opened yet.  Sigh.  (I think this was roughly the 
> same problem with why it was difficult to de-register the package in 
> Ned's earlier update.)  My fresh image still knows that it has 
> 'SARInstaller for 3.4' installed, though... it shows up if I open a 
> PackageLoader later.
> 
> I'll leave this Doit out of the update stream for now, unless we find a 
> better fix.
> 
> (Is there a simple way to populate the 'cards' dictionary in 
> SMSqueakMap?  That seems to be the problem.)
> 
> - Doug
> 
> 
> 
> On Wednesday, August 6, 2003, at 04:17 AM, goran.krampe at bluefish.se 
> wrote:
> 
> > Doug Way <dway at riskmetrics.com> wrote:
> >>
> >> On Tuesday, August 5, 2003, at 03:56 PM, Ned Konz wrote:
> >>
> >>> No. It turned out to be harder to de-register in the middle of 
> >>> loading
> >>> than I'd thought.
> >
> > Yeah, we probably need better "hooks" (for doing stuff afterwards etc)
> > in SM1.1+ when it comes to the installers etc. I will not bother
> > changing that stuff in SM1.1 though. Too bug prone.
> >
> >>> Though you could do this:
> >>>
> >>> SMSqueakMap default installedPackagesDictionary removeKey:
> >>> (SMSqueakMap default cardWithName: 'SARInstaller for 3.4') id
> >>
> >> This seems to work.  Assuming this is reasonably safe, maybe we should
> >
> > Should be safe. There are no other places (Except for the ChangeLog of
> > course! But we can't do much about that - replaying changes will get
> > this back, as would the #recreateYaddayadda method) with this state.
> >
> > Note that the above clears the full install history for the package
> > named "SARInstaller for 3.4", but in this case this sounds like what 
> > you
> > want to do.
> >
> >> add this with the next batch of updates, to avoid the confusion that
> >> Joshua ran into.  (For all practical purposes, if you follow the 
> >> update
> >> stream, SARInstaller for 3.6 is installed after the one for 3.4 and
> >> replaces it, so we don't need to list both of them as installed.)
> >
> > Sounds correct to me.
> >
> >> - Doug
> >
> > regards, Göran