[Squeakfoundation] SqueakMap in the image (was Re: Incorporating removals & KCP stuff)

[goran.krampe at bluefish.se]

Hi!

Doug Way <dway at riskmetrics.com> wrote:
> So in other words, I think we should be able to go ahead and add  
> SqueakMap to the current image?  It will certainly be part of the Basic  
> image, and would probably toward the end of the list of items removed  
> from the Minimal image (after most development tools, Morphic, MVC,  
> etc., are already removed).
>
> We will simply "promise" not to use the main update stream to change  
> code that resides in packages.  The only exception would be SqueakMap  
> itself, which I guess also happens to be a package.  But I don't think  
> that's a major problem... yes, the update stream may include major  
> upgrades to SM (such as SM 1.1) which simply overwrites the old package  
> in the image.

Ok, some reasoning here:

1. SM is a package. As it should be. As all things will be.
2. Basic should include SM and a bunch of other "tools" too IMHO. Like
DVS. Still as installed packages of course.
3. The current image is transforming itself into Minimal. We said
earlier that it is transforming itself into Basic but I don't agree. For
example, it doesn't contain SM nor DVS so... :-) By definition it is in
some ways actually "smaller" than Basic!
4. I repeat the above just to make sure we agree: The current image is
transforming itself towards Minimal. The updatestream is thus attached
to Minimal.
5. So what we have today is a large Basic-looking *Minimal* that still
includes many wannabe-packages BUT ALSO does not include SM, DVS, SAR
etc.
4. When we release 3.6 we should have:
	a) a sortof Minimal image. A very large one, but still going towards
Minimal.
	b) a loadscript that can bring this image upto Basic.
	c) another loadscript that can bring Minimal upto Full. It could even
be "smart" so that it can be applied to a Basic image too.
5. But on the road towards 4abc - what does the image contain that we
are working in? We don't want to work inside Minimal! We want to have
Basic.

Aha. So the 3.6a image I have sitting on my harddrive with a
updatestream connected to - what IS IT? My conclusion: It is the Minimal
image with *packages installed* so that it looks like the Basic image
that 4b above will produce.

Ok, back to the issue at hand: SM. And IMHO DVS, SAR and Package Loader.
And perhaps one or two more I am forgetting right now. My reasoning
above may sound like I don't want to introduce SM into the image - but
in fact I do. :-) But not as "just another changeset". I want them
*installed as packages*.

What this means in practice is the following:

We should issue updates through the update stream that installs these
puppies using SM! The SM bootstrap changeset (the one that you get if
you do the "Open packag loader") makes it look like SM itself was
installed through SM (though of course it wasn't).

I know that Scott Wallace earlier argumented to put SM into the image -
and I strongly objected. I still object to simply "filing it in" just
like *any changeset*.

In short - we can issue an update that simply runs the bootstrap. We can
keep the bootstrap code in place for a while.

> (Then there's Andreas' new stuff which supports update streams on  
> individual packages, which I haven't looked at closely yet... I'm not  
> sure if that would make a big difference for this particular case.)

I don't think so. I may try it out but I can't see how they have
anything to do with us just yet. That package could OTOH be a candidate
for Basic of course - just like DVS, SAR etc.

Phew - so what do you all say? Does my analysis above sound reasonable?
I find it strange that it seems so hard to define what things are - we
really are creatures of habit. Hard to let go! :-)

> - Doug Way

regards, Göran