[squeak-dev] Re: About unloading of packages in the most recent Squeak 4.1 trunk

Andreas Raab andreas.raab at gmx.de
Tue Aug 24 22:04:28 UTC 2010


On 8/24/2010 2:12 PM, Eliot Miranda wrote:
> I always appreciated the 95% rule, a.k.a. don't let the perfect be the
> enemy of the good.  Right now if one removes all packages and updates
> one gets an ugly mess one can wade through with the debugger.  If one
> were to simply skip the packages not in one's image one could certainly
> get to a point that might miss a required package, but one could also
> update without wading through the mess, without having to go through the
> remove unloadable packages step and without having to go through
> whatever other steps one had gone through to produce a finished image.
>
> E.g. take my OS Cog VMMaker image which has been derived from an unload
> step to be nice to svn users; the image is half the size of the normal
> one.  It's a mild pain to build, loading packages, adding workspaces and
> repositories etc.  Yes I could automate all this but it would be much
> nicer to build it once and periodically update it.  I don't care if it
> misses some required package; I can deal with that issue when I get to
> it.  But not being able to update without wading through mud is, to put
> it mildly, a downer.

I don't think you understand what I mean by "required" package :-) 
Consider that we're splitting the Morphic package along the lines that 
Pavel proposed. We add a MorphicWidgets package that includes all the 
Pluggable*Morphs. The problem is that the next version of the Morphic 
package will show these as REMOVALS so if you update the Morphic package 
and leave out the MorphicWidgets your image is an instant goner. That's 
what I mean by "required"; not some random goodie that nobody cares if 
it's absent.

Worse, this wouldn't just happen to people who have deliberately chosen 
to update only a subset; it would happen to *everyone* updating their 
trunk images and make it pretty much impossible to perform such 
operations. Unless we can find a solution to this problem, I think 
Bert's alternative is the only reasonable one - add an explicit list of 
ignored packages for the updater and you can add to that list whatever 
you want and it won't get updated. You'll have to deal with the 
consequences if something goes wrong there but as you said, you can deal 
with that when you get to it.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list