Package Update Installation Anomalies

Andreas Raab andreas.raab at gmx.de
Thu Mar 18 01:44:30 UTC 2004


> It's possible for a monolithic image.  I'm not convinced it works for
> multiple packages.  It seems like you could get into some really messy
> ordering stuff if you had two concurrent update streams that were
> modifying some of the same classes.  And the amount of work that Doug &
> co put into managing the Squeak update stream isn't something I would
> want to do for every package I maintain - which is probably why you
> don't see similar streams for anything but the base image (even though
> Andreas posted some code to allow this a while back).

You know, that's a truly interesting question. I thought about these issues
for a little and it actually occurred to me that SM is heavily built on the
assumption of "monolithic packages" (if you excuse the play on words ;-)
IOW, one of the basic assumptions of SM is that you always ship a "complete
package" - maybe having some dependencies to others but the model clearly
isn't geared towards saying that you manage an incrementally evolving
system. MC takes this to the extreme in some ways - for getting a one-line
fix out I send a 200k MCZ over the wire. In some ways that means we really
don't understand what the client actually *wants* from us, so we just throw
everything down the wire in the hope that either the client can make some
sense out of it (like MC actually making a diff on the stuff) or just
blindly takes it without looking left or right.

But if you start to think about an evolutionary model where you'd really
take updates from lots of different places it throws various of the basic
assumptions that we use today right out of the window. Maybe up to a point
where it gets questionable even to think about maintaining a system with any
kind of "files" whatsoever - wouldn't it be much more useful if a smart
client and a smart server could negotiate what server has, the client could
say what it wants and they both figure out how to get it done? Hm....

Cheers,
  - Andreas




More information about the Squeak-dev mailing list