Subject: Package Paths Proposal v3
To: None <tech-pkg@netbsd.org>
From: Todd Vierling <tv@pobox.com>
List: tech-pkg
Date: 12/18/1998 10:12:12
Addressing some concerns, here it is again.

=====

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 architecture 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.  It is known that configuration files
   are typically host-specific, and that a user may at his/her discretion
   use symbolic links to share particular configuration files. 

3. It must be possible to have the package system install files in the same
   locations as system binaries, and 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 is typically
   /usr/pkg.

    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) The user may create $PREFIX as a directory, separating all but
       configuration and host volatile files from the rest of the system.

       [The default setting between (a) and (b) with a `shipped' system
       is OUTSIDE OF THE SCOPE OF THIS PROPOSAL, and should be discussed
       in a different thread.]

    c) Special packages, such as those intended to replace system binaries,
       should install binaries in $PREFIX, rename the appropriate system
       files to `file.old', and if the user chose (b) instead of (a)
       above, use symbolic links to point to the proper paths in $PREFIX.

2. Programs will be compiled to find their data and modules under $PREFIX
   in bin, sbin, lib, libexec, libdata, share, as per hier(7) (a similar
   fashion to the subdirectories under /usr/local).  These would then equate
   to paths such as /usr/pkg/bin, /usr/pkg/sbin, etc., for the separation 
   case, and /usr/bin, /usr/sbin, /usr/lib, etc., for the intermix case.

3. 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 /etc.  If not, copy the
       copy the sample config set over to /etc.

4. Volatile files go in /var as per hier(4) and do NOT go in $PREFIX/var.
   These are most often host-specific and usually host-byte-order dependent
   in the case of binary volatile files.

5. 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
   /etc config files and /var files).

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