[ On Thursday, August 21, 2003 at 14:00:56 (-0400), Todd Vierling wrote: ]
> Subject: Re: Package Views Integration (finally!)
>
> On Thu, 21 Aug 2003, Greg A. Woods wrote:
> 
> : Binary packages are exactly the place where I definitely do not ever
> : want to use any depot-like scheme.
> 
> If pkg_add lets you choose how it's installed, what's the difference?

How can pkg_add deal with the versioning of configuration files and
other internal interfaces?  It can't.

Generally speaking allowing multiple variants of a package to be
simultaneously installed requires versioning the configuration files
which means referencing those configuration files in their depot
directory, not in the "common" link farm.

Configuration files are just the tip of the iceburg.  Every file that
has a potentially different API/ABI/UI depending on the variant of the
package _must_ be explicitly referred to by its versioned name (i.e. be
referred to directly in its depot directory).  I.e. pkg_add cannot
possibly transmogrify a binary package that was compiled with the link
farm in mind so that it can be installed directly without using the link
farm.

The link farm can only be used for very trivial command-line UI
compatability -- i.e. for the likes of keeping user's $PATH settings
short and simple.  The link farm cannot safely be used to reference any
components which may have a different API/ABI/UI between package
variants.

The depot-style scheme is fine if that's what you _really_ need for some
strange reason, but if you don't _really_ need it _badly_ then it only
gets in the way and introduces many more maintenance and management
headaches, not to mention leading to serious end-user confusion in
situtations where it's not implemented very carefully.

It also seems to me that NetBSD pkgsrc for "release" binary package sets
really does not need `pkgviews' or anything like it.  Some pkgsrc
developers and maintainers might need it to make their lives easier, but
nobody else _really_ does since almost the important packages which
people commonly already do this with already support simultaneous
installation of many variants natively anyway.

If large and complex packages like GCC and Emacs and such (and smaller
similar ones like GNU Autoconf, etc.) can manage to work properly with
different simultaneously installed variants on the same host and they
can do it without the help of some kind of depot-scheme then any other
package can just as easily do likewise.  I.e. fully supporting multiple
installs of packages in release versions really should be done only with
care and deep understanding of the package, and hopefully with the
support of the package author(s).

-- 
						Greg A. Woods

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