If anything, the number of such (similar yet different) systems
is an indication that one size does NOT fit all.  For those
interested, i really suggest looking at some of the more
different styles and the papers written about them to get a
good idea.  Why so many differences?  Simply because different
environments bring different requirements.  Nothing really
surprising here.

On Oct 16, Greg A. Woods wrote:
[...]
| Finally it should be said that the goals of pkgsrc are quite separate
| from the goals of other packaging systems that try so hard to keep
| track of multiple versions of the same packages.  (at least that's how I
| interpret the goals of pkgsrc)
| 
| So, I really have to ask what benefit anyone expects to get from trying
| to merge the likes of epkg/encap/Modules/etc. with pkgsrc.

pkgsrc already keeps track of different packages, which files
belong to which packages.  This is a very big part of what
these systems often try to do.  pkgsrc does it well, but
requires more work in the sense that packages have to be
defined/created/maintained.
The above systems don't require such work, you just slap
packages on the system and symlink them.

the seemingly extra work required by pkgsrc is a lot more
justifiable because of the audience.  For a single site, it's
harder to see the point, and other solutions may seem more
attractive (although i understand that some like epk/encap
also promote the redistribution of packages).

| >  I remember that at one point we had half-a-dozen different 
| > versions of Perl installed, and too scripts many depending on one version 
| > or another.   Even worse was trying keep CLASSPATH straight for the
| > various Java's on the system.
| 
| Yes, the ability to have multiple versions of software simultaneously
| installed on a system really does require a heck of a log more
| discipline in the users, especialy if we're talking about software tools
| vs. software developers.  Sometimes a project really does need multiple
| versions of their compilers or interpreters or libraries and such, but
| the support issues must be really very carefully spelled out for all the
| users and admins should not enter into such a situation without extreme
| care and very good justification for doing so.

There is at least one of these systems (SEPP?) that was designed
especially for this, and made heavy use of wrapper scripts to
massage the environment and make it transparent to the user
who could actually select whatever package and versions to
use in a very simple and straight forward way.  (it's been a
while since i read all these papers.)  Even though, i agree
with you that things can easily go wrong.

Things are indeed a lot easier if all users are presented with
the same exact set of versions.  Totally hiding the real
location of packages from users is something i'd be keen on
doing, which i guess is possible by using hard links rather
than symlinks (but that makes managing the whole system much
less efficient!).

|                                                 Ideally some
| consideration should also be given to implementing some scheme for usage
| monitoring so that hidden dependencies don't get out of hand.

This is what bothers me with all these systems:  most dependencies
are hidden.  And that's also what i probably view to be the
most interesting feature of a well conceived package system:
inter-package dependencies are exposed and registered.  When
you upgrade one package, you should be able to do it without
breaking the 10 other ones depending on it, and if the new
version does cause breakage, then the simple way to do it is
by leaving the old one around until the breaking packages can
be/are upgraded.

This is fairly easy to achieve with symlinks between packages
which, the last time i checked, no existing system explicitely
supported.  (This is how swpkg <http://web.taranis.org/swpkg/>
came to be.)  It is more work, but i find it to be a lot
cleaner, predictable and stable.

It is now the third time i start a software package base using
symlinks, twice from scratch and with full inter package
dependency management, once (in between) on top of an existing
/usr/local and without the inter dependency management.  In
other words, i'm a big fan of this way of doing things for
these two reasons (good interdependency management and easy to
slap packages on the system and keep track of them all).

But it significantly increases complexity which isn't something
i'm fond of.  Merging pkgsrc with a symlink system just for
the sake of it and/or multiple versions of the same package
just doesn't seem to be worth it.