[ On Wednesday, October 16, 2002 at 15:55:29 (-0700), David S. wrote: ]
> Subject: Re: Merging pkg_* and epkg/encap
>
> 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.

Hmmm....  indeed!  The only thing these kinds of packaging systems solve
that's not already directly solved in the likes of pkgsrc + pkg_install
is the ability to more easily install multiple versions of packages on
the same system.

However it's probably not too hard to build a very good argument showing
that all of the rest of what those packaging systems offer is already
better handled in pkgsrc and with pkg_install.  I would say that even
applies in most situations to other similar systems like Depot which
focus more on the distribution of pre-configured software to clusters or
workstations.

Even the ability to easily simultaneous install multiple versions of
packages isn't terribly hard to achieve with pkgsrc as it stands, and
there's quite a long and successful history of doing so with packages
already in pkgsrc (and FreeBSD ports).  Of course it's easier to do for
packages which already include some support for this directly in their
"vendor-supplied" build systems (eg. those with Autoconf+Automake), but
to do it for any package is just a matter of maintaining a few extra
makefile patches or custom install rules.

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.

>  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.  Ideally some
consideration should also be given to implementing some scheme for usage
monitoring so that hidden dependencies don't get out of hand.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>