Daniel Vainsencher wrote:

>About the other side of the equation -
>The way I did the Celeste removal, and the way I think most removals are
>done, and definitely all removals should be done, is that once removed,
>the image is left pluggable with regard to the package. That is,
>reloading a package does not modify code in the image.
>  
>
Yes, that should be the goal.  Hmm, I wonder how many of the currently 
removed packages live up to this?  I suppose I could fire up the 
ConflictChecker and find out...

(And I assume by "not modifying code" we agree that class extensions are 
allowed, but overwriting methods is not allowed.)

>The application removed should also have its limits clearly marked - it
>either belongs to a specific class category, or is described by a
>PackageInfo.
>
>These together mean that - 
>1. Packages removed can be reloaded/removed at will.
>2. Changes to such packages can be easily identified using PackageInfo +
>DVS.
>
>Packages that don't adhere to these rules should be fixed or declared
>unofficial and removed from the Full load script.
>
>I don't know whether usage of DVS should be mandatory - I think usage 
>of PackageInfo should be. But I definitely think that PackageInfo, DVS 
>and SM are things anybody interested in Squeaks future would do well 
>to take a serious look at. Not for the specific implementation, but for 
>the implications on what we're capable of.
>  
>
It sounds like we're agreed that PackageInfo should be something of a 
standard for now.  We could plan on adding PackageInfo to the update 
stream soon.  (Possibly along with SqueakMap and SAR.  Well, depending 
on whether those get added to the update stream or kept on some sort of 
Basic Image package... more on that later.)

- Doug Way