tech-pkg: Package Paths Proposal v3
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)