On May 17, 2004, at 3:55 AM, goran.krampe at bluefish.se wrote:

> 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.

This is fine for packages that are dependent on the update stream.  The 
problems arise when the update stream is dependent on a package.  Take, 
for example, the Compiler, which has recently been (sorta) split into 
its own package.  It's not unreasonable to think that there may be some 
tool like the Browser, still maintained using changesets in the stream, 
that will at some point acquire a dependency on a particular Compiler 
version.  If there's nothing in the update stream to ensure that the 
user does in fact have that version of the Compiler loaded, it's quite 
possible that they will end up with a trashed image.  That's why it's 
important to have *something* - whether a command to load from 
SqueakMap, a changeset, or a .mcz or SAR file - in the update stream to 
bring in the new package versions that make up the basic image.  We 
*can't* just say that because it's on SqueakMap, the user is 
responsible for updating it themselves.  The same concern applies to 
having an independent update stream for each package - it's too easy to 
get out of sync.

Given the desire to have the update stream be self-contained, without 
depending on external servers (which is fair enough, IMO), I think the 
best solution is to expand the options for what can go in it, as I 
think Ned suggested.  Just allowing changesets seems too narrow - 
limiting ourselves to "source code in files" like that feels, well, 
quaint ;).  And as a practical matter, it's annoying and time consuming 
to have to convert everything into a changeset.  But we should be 
careful about opening things up too much, since any format we do allow 
needs to have support in the base image.  If we have Monticello 
packages in the update stream, for example, we'll want a real 
Monticello loader (capable of doing package updates), and not just the 
bootstrap installer we have now.  I'm ok with this, but I don't know if 
everyone else is.

Avi