Curt, considering I've completely butchered this, could you give me some
input?  ;)

Here's the revised proposal.

=====

1. /usr is designed to be shared amongst multiple machines of a single
   architecture. Therefore, in the default configuration, files that are not
   exactly the same for all machines of a single archtecture should not go
   here, and files that are written other than at package installation
   should not go here.

2. /var and /etc are local to the current machine. As per the hier(8)
   manpage, /etc has configuration files and /var has log, temporary,
   transient and spool files.

3. It must be possible to have the package system install files in a
   separate area, where they are not mixed in with the standard system
   binaries.

Locations:

1. The package tools will install things in $PREFIX, which defaults to
   /usr/pkg. This will normally be a directory (created if it does not
   exist).

    a) The user may create $PREFIX as a symlink to /usr, causing packaged
       binaries to be intermixed with the operating system files themselves.
       This has some advantages, including that paths don't have to be
       changed; users just use their usual paths to find the installed
       packages. (cjs: In my personal experience, this would make it easier
       to convert Linux users.)

    b) Special packages, such as those intended to replace system binaries,
       should install binaries in $PREFIX, rename the appropriate system
       files to `file.old', and use symbolic links to point to the proper
       paths in $PREFIX.

2. Files will be compiled to find their data, and installed, under $PREFIX
   in bin, sbin, lib, libexec, libdata, share, as per hier(8).  These would
   then equate to paths such as /usr/pkg/bin, /usr/pkg/sbin, etc., for the
   default case, and /usr/bin, /usr/sbin, /usr/lib, etc., for the intermix
   case.

3. Configuration files: Programs use configuration files from /etc (not
   $PREFIX/etc) as the compiled-in default. Generally, subdirectories
   (/etc/<pkgname>) should be created for packages that have more than one
   or two config files. Sample configuration files should be placed in
   $PREFIX/share/examples/<pkgname> (pkgname may be omitted if a single,
   uniquely named config file is used). The general algorithm for
   installation is:

    a) See if example config files exist in $PREFIX/share/examples. If they
       do, rename them with a .old extension. (This facilitates a later
       diff3(1) or merge(1) to see and deal with configuration options that
       are new or changed when a package is upgraded.)

    b) Install sample config files in $PREFIX/share/examples/<pkgname>.

    c) See if `real' configuration files exist in $PREFIX/etc. If not,
       copy the sample config set over to $PREFIX/etc.

    d) See if `real' configuration files exist in /etc.  If not, add
       symlinks for each from /etc to their corresponding files in
       $PREFIX/etc.

4. A user may choose between shared and unshared configuration files at
   run-time.

    a) If the user wishes to use shared config files, he/she should edit the
       config file(s) in $PREFIX/etc.  The previously installed symlinks
       (see 3d) would take care of finding them at run-time.

    b) If the user wishes to use unshared config files, se/she should remove
       the symbolic link for the appropriate file(s) in /etc, and copy the
       example file or config file from $PREFIX/etc to /etc.  A file in
       $PREFIX/etc will not be read by its program in this case.

5. Volatile files go in /var as per hier(4) and do NOT go in $PREFIX/var.

6. Startup scripts: daemons that start at boot time should have a start/stop
   script available. This should be placed in $PREFIX/share/rc.d/<pkgname>.
   It should accept the following arguments:

    start:	start the daemon
    stop:	stop the daemon
    reload:	reload configuration files

   The `stop' item is so that the script can clean up things that the daemon
   doesn't (such as /var/run/xntpd.pid, for xntpd) and the reload is so that
   the script can do whatever is appropriate to make the server reread its
   config files (send a sighup, stop and start for dhcpd, mysqladmin reload
   for MySQL, etc.)

   These should return a status code, but should not produce output except
   in the case of an error. These scripts are likely to be called from
   another program, though they may also be run directly by the user.

7. Package metadata: the files describing a package install (PLIST, etc.) go
   in $PREFIX/libdata/pkgdb. That way if a package is installed on a one
   system sharing /usr with others, it `appears' on the other systems (minus
   config files and var files).

Notes:

Notice that, unlike the current situation, things are set up for shared
systems by default, and it is a single step to turn that off. (Right now
it's several steps to put in symlinks to turn on sharing.) Keep this in mind
when suggesting changes.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)