Subject: Re: Package Paths Proposal
To: Curt Sampson <cjs@cynic.net>
From: Todd Vierling <tv@pobox.com>
List: tech-pkg
Date: 12/11/1998 21:58:24
As per some of the suggestions I made in private mail, I've pruned this a
bit; see below and add comments.

The biggest changes are, of course, that /pkg has no `usr' subdirectory (to
reduce a *lot* of confusion possibility), /var is used directly, and
/pkg/etc contains shared config files that can be replaced simply on a
per-host basis, even with binary pkgs.

=====

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 /pkg. This will normally
be a symlink to /usr/pkg.

The user may set this symlink to /usr, causing the package stuff 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.)

[tv: the other `advantages' have been pruned because there are some
logistical problems with (b) and (c) that symlinking /pkg to / alone doesn't
solve, particularly for those who *want* a near-pure separation of system
and pkg.  Also, (d) is addressed by a changing of the handling of config
files, below.  For completeness, (b)-(d) were:

    b) New package binaries (such as sendmail or named) replace
    the current system binaries, thus avoiding the problems caused
    when two different versions of a program are installed in
    different places on the same system.  [tv: this has other logistical
    problems, so symlinking to / doesn't quite cut it, but it helps.]

    c) Package binaries that replace the current system binaries
    will still start as normal from /etc/rc.conf, etc.

    d) System binaries, package binaries and locally compiled
    binaries all use the same configuration files, thus getting
    rid of some config file versioning problems, and making upgrades
    easier.

--]

2. Files will be compiled to find their data, and installed, under /pkg 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 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 /pkg/share/examples/<pkgname>.
The general algorithm for installation is:

    a) See if example config files exist. If they do, rename them
    with a .old extension. (This facilitates a later diff(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 usr/share/examples/<pkgname>.

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

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

4. Volatile files go in /var as per hier(4) and do not go in /pkg/var.

[tv: X11R6 suggestion stricken, as /pkg has no `usr' subdirectory and it's
not clear to me that putting the X11 distribution under /pkg has any real
value, since imake expects it elsewhere anyway.  We need to do something
better with xpkgwedge/build procedures for X11 pkgs.  For completeness, it
was:

(5.) /pkg/usr/X11R6: if the user elects to symlink /pkg to some place
other than root, there should be a strong suggestion that he symlink
/pkg/usr/X11R6 to /usr/X11R6, due to the problems that crop up when
you try to put X11 elsewhere. (Unless, of course, you're doing
PLIST development or some such, in which case you probably don't
want to be dumping crud in your /usr/X11R6.)

--]

6. Startup scripts: daemons that start at boot time should have a start/stop
script available. This should be placed in /pkg/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 /pkg/.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:

1. 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.

[tv: second part stricken, as the removal of X11 and the `usr' subdirectory
makes most of it moot.  For completeness, it was:

(2.) We need to document the various levels of sharing that people
might want to use, and how to set them up. The ones I see right
off are:

    a) Everything shared, fully integrated: /pkg -> /

    b) Nothing shared, completely separate: /pkg -> /usr/pkg,
       seprate filesystem, whatever.

    c) Nothing shared but X11: as b) but with
       /pkg/usr/X11R6 -> /usr/X11R6.

    c) Shared, but packages are seprate: as c) but /pkg/var ->
       /var, /pkg/etc -> /etc.

--]

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