On 13.04.2013, at 11:24, Frank Shearar <frank.shearar at gmail.com> wrote:

> On 13 April 2013 19:19, Frank Shearar <frank.shearar at gmail.com> wrote:
>> On 13 April 2013 18:25, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>> 
>>> On 13.04.2013, at 08:05, Frank Shearar <frank.shearar at gmail.com> wrote:
>>> 
>>>> On 12 April 2013 19:00, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>> 
>>>>> On 12.04.2013, at 11:32, commits at source.squeak.org wrote:
>>>>> 
>>>>>> Frank Shearar uploaded a new version of System to project The Inbox:
>>>>>> http://source.squeak.org/inbox/System-fbs.523.mcz
>>>> <snip>
>>>> 
>>>>> I'd rather use "Smalltalk cleanUp" which does almost all of what you listed. This is more future-proof. If something is missing, add it to the cleanUp mechanism (that is, implement a class-side cleanUp or cleanUp: method).
>>>> 
>>>> So just to be clear you mean unloading packages should be:
>>>> 
>>>> unloadPackages: somePackageNames
>>>>   "Go unloading"
>>>>   somePackageNames do: [:pkgName|
>>>>                   (MCPackage named: pkgName) unload.
>>>>                   MCMcmUpdater disableUpdatesOfPackage: pkgName.
>>>>                   ].
>>>>   Smalltalk cleanUp: true. "Needed to trigger the MCWorkingCopy's
>>>> #cleanUp: of obsolete PackageInfos; could of course change that method
>>>> to always do this."
>>> 
>>> It should *not* flush all PackageInfos, but only the ones that were actually unloaded. And possibly that should happen in #unload itself.
>>> 
>>>> where we have another commit implementing Preferences >> #cleanUp ?
>>>> 
>>>> frank
>>> 
>>> 
>>> No, "cleanUp: true" should only be done in the release process, or manually, because it will actually modify the image beyond emptying caches. E.g., I might like keeping package infos around even if there is no associated MC package. The system should not simply discard them. Same for empty system categories: If I create a category manually, the system should not simply trash it. Etc.
>> 
>> That sounds like exactly the _right_ thing to do, but perhaps I should
>> indicate that by putting this method with the ReleaseBuilder. Because
>> this _is_ about a release-making like process, in that I'm wanting to
>> cut things out of the image... but at the moment the 4.5 image I use
>> had things ripped out in an untidy manner.
> 
> Actually, no. I don't want to clean the world. I want to remove every
> trace of a particular package, and this unloadPackages: should
> aggressively clean up only that state associated with the package:
> strip menu items, registered apps, and so on. So it shouldn't call
> Smalltalk cleanUp at all, aggressive or otherwise, I would think.
> 
> frank


The regular Smalltalk cleanUp should be perfectly safe to call any time. So you would only need to implement the stuff specific to package unloading.

- Bert -