Tim Rowledge <tim at sumeru.stanford.edu>  wrote...
>Whatever the actual implementation for packaging, please, let's not end
>up with the utterly infuriating problem I keep hitting everytime I am
>unfortunate enough to have to try to load anything on linux (OK RedHat
>in particular, but let's not quibble about inconsequentials) and get
>told 'oh this depends on package
>furble-unco-wibble_pre1.x86-k.bar.srpm'. Yeah? So what? Where is it?
>What is a compatible version? Do I already have one?
>
>When you're developing a package it doesn't matter much, but once the
>package is disseminated a correct list of pointers to compatible
>co-dependents is important. The act of 'publishing' a package ought to
>include _insisting_ on all these things being correctly specified. I'd
>imagine a decent database could be kept of dependencies in _both_
>directions, so that if a newer release of something you depended upon
>were stored, you (in either the sense of the author or the community at
>large) will get warned.
>
>Another annoyance would be the nonsensical dependence; you have to load
>a umpteen gazillabyte package just for the logical equivalent of a
>single header file.

I think this is related to one of the desiderata:  Things should be as easy for the weekend hacker after modules as they were before.

...which would mean that if I get a Squeak release, whether delivered as a kernel and a pile of packages, or as a nicely partitioned image with everything loaded in, I have all sources right there in some local disk files.  I go to Kilauea, I'm still in total control.  IF I want to play Top Gun with all the other developers, I can change a preference and get hooked up with some fancy remote database and THEN I can get their changes, and share mine back.  'Fetch updates' would be a request to update packages that have changed recently (preserving the nice incrementality may take some thought).

	- Dan
--