Subject: Re: Merging pkg_* and epkg/encap
To: None <email@example.com>
From: David S. <firstname.lastname@example.org>
Date: 10/16/2002 15:55:29
> 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.
> 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 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.
> > : http://www.encap.org/
> > --
> > Jonathan Perkin - Internet Operations Engineer - BBC Internet Services