"Andrew C. Greenberg" wrote:

> It isn't necessarily a horribly monumental idea if you distribute the
> effort, first by building the "ports tree" edifice and toolit, and
> then facilitate the building and submission of ports and similar
> tools by others.

A good example of this is in the Linux community, where the .deb (Debian)
and .rpm (RedHat) formats for packages allow for simple dependency management.
Granted, it's more work to use these formats than just to file out a change
set, but people seem to be able to do it.

These formats require package version dependencies to be specified, and permit
pre- and post- install scripts to be run.

One drawback is the lack of traceability in Squeak: the change sets are
not sufficient to support this kind of arrangement. Look at Envy, for instance,
for an example of a system that would provide the support needed.

An important concept in Envy is that of application versions/editions. Instead
of having a dependency on a given version of a _method_ (which is what we get
when we deal with change sets), Envy users deal instead with a larger unit of
release (the Application or the ConfigMap).

It seems to me that this would be the required level of functionality if we
expect to remain robust in the face of arbitrary change sets.

Another parallel is CPAN (the Comprehensive Perl Archive Network). I have a
couple of Perl modules in the CPAN, so I'm pretty familiar with the problems
there.
The CPAN tools (and MakeMaker) allow for the specification of dependencies
in terms of versions of other modules (and on versions of Perl itself). Each
module has (should have, anyway) a numeric version number, and other modules can
specify dependencies on _at least_ that version number. This works pretty well,
assuming people keep backward compatibility in newer versions of modules. (A
module
provides both methods and loose script bits (initialization, etc.)).

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com