On maintaining a consistent update stream

goran.krampe at bluefish.se goran.krampe at bluefish.se
Mon May 17 10:55:57 UTC 2004


Colin Putney <cputney at wiresong.ca> wrote:
> 
> On May 14, 2004, at 6:10 PM, Doug Way wrote:
> 
> > I was somewhat hesitant to allow updates which directly load packages 
> > from SqueakMap.  This was discussed a few months ago, though, and 
> > there wasn't any significant opposition to the idea.  See:
> 
> I know this idea is pretty radical, but I figure I'll throw it out 
> there anyway. Maybe it will grow on people.
> 
> Why not just keep packages out of the update stream entirely? That 
> would make the update stream only responsible for managing the Minimal 
> image, and avoid all these issues, entirely.
> 
> We could put a "Basic Image Assember" on SqueakMap, just as we do for 
> the Full Image. This wouldn't be anymore difficult for users than what 
> we have today. Instead of sending an posting "41 new updates" to the 
> list, you'd post "3 updates to the basic packages". Then we'd all open 
> up the package loader and click on "update all packages"
> 
> Yeah, there are probably a few little kinks and gotcha's here and 
> there, but nothing we can't solve.

Since my memory is so weak I can't remember the exact reasons for
issuing SM commands as updates! :)

Thinking "loud" it seems to me that the update stream is currently the
only way for us to "force" a package update on to the user. And why do
we want to do that? For example, if there are modifications to base
classes that makes say the package loader stop working - then we can
issue an update to bump up the package loader before introducing those
base modifications.

Granted it isn't that easy - an older image that han't loaded updates
can today *also* bump up the package loader - and the new release of the
package loader could potentially not work in the old un-updated image!

So the issue here is that we have two parallell tracks:

1. The base image using the fine granular update stream.
2. All the packages that comes more coarsely in new releases.

Now, how *should* we solve it? IMHO the solution is to have better
dependency management. (cough) Yes, I *know* - the fact that we don't
have it yet is mostly my fault. But hear me out. :)

If the package releases "know" their dependencies the problem with
installing a new release into an old image could be prevented. The map
would show the user that there is indeed a new release available, but it
could also show that it is currently not installable since the base
image needs to be updated to level X.

And of course, it could also need newer releases of a bunch of other
packages as well.

So we would need to declare not only dependencies on other package
releases, but also a dependency on a certain update level of the image
(optionally). In fact, if we start registering "base images" on SM we
might even need to refer to those too, like say the Squeakland image or
the Small-land image or the Squat kernel or whatever.

Btw, my weekend turned out totally busy unfortunately, but I have
scheduled this evening for SM work. :) And yes, mirroring is high up on
the todo list - it isn't hard to do - just needs a tweak or two to the
code and the correct rsynch incantation.

regards, Göran

PS. The short of the above is that, yes, I think we can stop doing SM
command updates, but we should of course also do a real push for adding
solid dependency management. And I intend to do exactly that as soon as
I get the "maintenance" releases of of SM base and the loader. :)



More information about the Squeak-dev mailing list