> 
> SEPP is another system which is somewhat similar in the sense that it
> makes a big symlink farm and also allows multiple installed versions.  Any
> idea how epkg compares to that?

Yet another alternative along these line is the 'Modules' package -
http://modules.sourceforge.net.  Rather than using symlinks, it allows 
for easy manipulation of PATH, MANPATH, and other environment variables.  
I have my doubts about all of these "multi-version" package systems,
though.  I've used 'Modules' in the past, and one consequence of it was
a great deal of system bloat.  When it's easy to have many versions of
a program around, you tend accumulate a lot more than need and should
have.  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.

David S.
 
> 
> 
> On Wed, 16 Oct 2002, Jonathan Perkin wrote:
> 
> > I've been pondering this a while, and unsure if anyone else has or
> > whether someone has been working on it at all..
> > 
> > The encap package manager[1] is based around installing all software
> > packages under their own directory in a specific hierarchy.  It's
> > something I use a great deal for locally-installed software as it keeps
> > everything neat and tidy, and makes it trivial to keep multiple versions
> > of software around and able to switch between them.  An installed
> > package is symlinked back into the main hierarchy and available for use.
> > 
> > For instance, my packages live in /cache/local/encap (e.g. epkg-2.2.6)
> > and are symlinked back into the /cache/local hierarchy so that:
> > 
> > lrwxrwxrwx   1 jonp     inet           28 Oct  3 13:54 /cache/local/bin/epkg -> ../encap/epkg-2.2.6/bin/epkg*
> > 
> > etc.
> > 
> > After the standard "./configure --prefix=/cache/local/encap/<package>-<rev>
> > make && make install" dance, software is installed to the /cache/local
> > hierarchy with a userland epkg(1) utility which creates the symlinks,
> > checks for clashes and creates a log.  Deleting the software is simply a
> > matter of removing the symlinks (which epkg(1) handles automatically).
> > 
> > I can see great benefits in merging this system into pkg_*, as it will
> > greatly help having multiple versions of binaries/libraries installed,
> > and also help the "make update" problem of re-installing everything if
> > one single package lower down the dependancy graph changes.
> > 
> > There are issues, especially having everything symbolically linked
> > (having to traverse those symlinks to get to real file for stat(2)
> > information etc, and speed issues), but hopefully with the recent
> > ld.so_elf updates the second shouldn't be that bad.
> > 
> > I'm willing to work on this, but need feedback as to whether it's worth
> > starting, or whether anyone has already done some work in this area, or
> > even if the pkg_* meisters have something cleverer up their sleeves for
> > future development.
> > 
> > [1]:	http://www.encap.org/
> > 
> > -- 
> > Jonathan Perkin - Internet Operations Engineer - BBC Internet Services
> >