Against package removal

Doug Way dway at riskmetrics.com
Thu May 8 18:37:06 UTC 2003


Markus Gaelli wrote:
> 
> Anthony Hannan wrote:
> >
> > The latest updates include package removals.  What does this buy me
> > except a smaller image file?  Who cares how big the image file is
> > especially once its downloaded.  Hard drives are big and virtual memory
> > only loads what is used.  So the only benefit is quicker initial
> > download, which is just a one-time event.  After that, you can download
> > incremental updates.
> >
> (...)
> >   With a full image, I find all dependent code and make
> > changes accordingly.  This allows me to make wholesale changes,
> > confidently.  I wouldn't be able to build a robust closure compiler if
> > I
> > didn't have Etoys, MessageTally, ProcessBrowser, ImageSegments, etc.
> > loaded because I wouldn't know to update them to work correctly with
> > the
> > new closure compiler.
> 
> Hi list,
> 
> I second this very strongly.
> I am also all for a tiny image,
> but _the_ image, which is _the_ image,
> we are talking about, when we talk about
> updates, for me still meant the "full" one.

We have discussed this in a few threads on squeak-dev and the SqF over the
last several months... we decided that removing packages and storing them on
SqueakMap was the simplest way to deal with breaking apart the image into
component parts that could be managed by a distributed community.  A more
robust module implementation can be added later.

There will still always be the "Full" image concept, though, with all of the
development and media content of the traditional Squeak image.  I agree that
we do need to make the Full image content easily available to everyone, so
that we can do all that good stuff like finding all senders/implementors.

> > So I recommend:
> > 1. Keep a single full image.
> > 2. Add module framwork to the image (a la ClassBoxes).  Modules not
> > only facilitate better structured code, but allows different behavior
> > to
> > co-exist in the same image without clobbering each other.  The module
> > framework can be added without displacing the current behavior
> > structure, allowing both structures to coexist and collaborate.  Then
> > classes and methods can be moved to modules as desired.
> > 3. Work on distributing the image (using technology found in Magma,
> > rST, etc).  This will allow us to share the same image and build a
> > collaborative world (a la Croquet).
> >
> Possible short term solution:
> Let us just acknowledge, that we want both,
> a minimal and a full image.
> 
> I think, it is already possible to build a smaller image and
> a big one automatically, so we just should have the possibility
> to download both of them. This wouldn't be a fork, as the big
> and the small one would share exactly the same code-base.
> 
> When we have that, (Guides?) suffixing the mail-prefixes
> like [ENH] or [UPDATE] with something like [FULL] or [MINIMAL]
> could help to end this discussion.

We discussed this a bit (about a month ago on this list I think), and as the
update stream maintainer, I decided that this would be too much of a
maintenance headache to coordinate two update streams like this.  (If this is
what you mean.)

We will definitely provide a Full image with the final 3.6 release (either as
an additional image download or perhaps a simple bootstrap from a Basic
image).  Providing this during the alpha cycle is the tricky part.

Part of the problem is that we don't have SqueakMap 1.1 yet, which would
support package versions and allow a dependency mechanism with which to build
a Full image easily, even during the alpha cycle.  For now, we'll have to
settle for something a bit clumsier and simpler.

Probably what we should do for now is create a "Upgrade to 3.6alpha Full
Image" package or similar, which anyone could install to upgrade to the
current Full alpha image.  This would simply re-install the current removed
packages (currently 9).  Someone would need to maintain this, though. 
Volunteers?

- Doug Way



More information about the Squeak-dev mailing list