Avi Bryant <avi at beta4.com> wrote:
> 
> 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.

As always, a very good observation from Avi! :) Ok... while
brainstorming on the subject (and thus we can throw more or less crazy
ideas out in the open) how about if the update machinery can check how
far it can go given the installed package releases in the image? Hmmm.

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

Well, I agree in principle. But we could also make the system a bit more
helpful like telling the user that, hey - might be wise to upgrade
package X and Y, etc.

Anyway, best would of course be if we had a good dependency model in
place and could move towards more packages.

But until we get there I think I agree with Avi that the packages that
make up the basic image should be upgraded "by the update stream" - and
typically *not* by the user him/herself. This means that the update
stream has full control over the Basic image.

>  The same concern applies to 
> having an independent update stream for each package - it's too easy to 
> get out of sync.

Yes, I would definitely not want us to use streams for the base
packages. It is complex as it is with the single stream we have today.
:)

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

I think this sounds a bit... needlessly complex. If we want to be able
to handle package releases - then why not just use SM? The "without
depending on external servers" can easily be remedied using mirrors etc.

My proposal is to:

1. Make sure we don't rely on unreliable servers. This involves mainly
making SM mirrors and adding the server side cache.

2. Add the dependency model ASAP. :) So that package releases can depend
on update levels.

3. Add the rule that the Basic image packages are only upgraded by
update SM commands. I can even make the loader aware of this so that it
will confirm any manual attempts to upgrade Basic image packages.

How does that sound?

> Avi

regards, Göran

PS. At one point we more or less agreed that Monticello could go into
Basic. I think it should.