> >
> >The structure you suggest (putting everything belonging to one package in a
> >single dir) seems reasonably to me, too. Using pkg_tools won't be a problem
> >this way, but you'll have to provide some methods so users don't have to
> >maintain a list of directories for $PATH, $MANPATH, etc. for themselves.
> 
> 	Now we are dealing with that using two methods:
> 
> 	1. Links in /usr/local/bin, /usr/local/man, etc. That way,
> when you upgrade to a new version of a package, just grep in that
> directories looking for references to the old /usr/local/install/foo,
> delete them, and make new symlinks. That can be easily automated.

You don't have to reinvent the wheel - have a look at 'Store', A System for
Third Party Software Installation and Maintenance. I love it, and as a
consequence, I don't use /usr/local anymore. We have also used it here at
the University for a while, and it works great. 

I admit that 'store' is intended to be used in large installations, with
file-servers serving multiple platforms. However, it organizes everything so
well, that I have chosen to use it on my stand-alone NetBSD i386.

>From the 'store' documentation:

What is STORE?

Store is a concept for handling third-party programs under Unix. 

The goal of STORE is to give administrators and users a framework that: 

     - provides a clear view on each single application, 
     - is transparent to users, 
     - allows handling several versions of one program, 
     - keeps information on local modifications, 
     - eases cooperation and sharing of applications between several
       organizations with different computer usage patterns, 
     - eases equivalent installation of programs between different
       hardware/software platforms, and 
     - lets administrators choose which applications to make available on
       each machine, so single applications may be added
     - and removed as needed. 

To provide these features, STORE is a set of programs, supporting a central
concept on how to organize software installation. The central concept is:

     - All files belonging to one single application should be kept
       together in one single directory tree. 
     - For each collection of machines in organizations in a cooperating
       STORE environment, there should be one and only
     - one such master directory for each application. 
     - An application may need some architecture dependent files, and some
       independent files. In STORE, an application has
     - several versions of architecture dependent files, and one common
       version of each architecture independent file. 
     - To ensure availability and acceptable access speed, the application
       packages should be automatically distributed to
     - local copies, enabling automatic propagation of changes in the
       original version. 
     - A virtual directory tree with symbolic links weaves together the
       multitude of packages, creating a "normal" tree for
     - the end-user and ensuring simple use of programs. 


For those who are interested in looking at store, you will find more
information at http://www.pvv.unit.no/~arnej/store/storedoc_2.html. Now -
this URL is old, and has not been updated for a looong time. Store has gone
through substantial improvements since then.

Version 2.2 of the store document can be found at 
'http://www.pvv.unit.no:1848/info/store.info'. 

I encourage you to give it a try. If you are using it on all software (like
me) you will find that it gives you the control you want over all packages. 

Bye,
-- 
Geir Inge Jensen                               Department of Computer Science
                                               University of Tromsų, Norway
SMTP : geiri@staff.cs.uit.no
URL  : http://www.cs.uit.no/~geiri/            Phone: +47 77 64 57 47