How about putting qmail (or at least the binaries) in /opt/local/qmail or
/usr/local/qmail? Apache has recently changed to /usr/local/apache for its
ServerRoot directory, and I personally like this method. I have recently
begun configuring most software I install to use /opt/local (which I have
/usr/local/ symlinked to.)
--Adam
-----Original Message-----
From: D. J. Bernstein <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, December 23, 1998 3:36 PM
Subject: /var, /opt, /package
:Juan Carlos Castro y Castro writes:
:> what's so special about /var?
:
:/var is universally available, and was almost universally available
:three years ago; it usually has lots of space; it is not shared across
:NFS. So people can just go ahead with the installation, with no risk of
:incorrect file sharing and with minimal risk of installation failure.
:
:More and more systems are being shipped with /opt, where each package is
:expected to have its own directory structure. Unfortunately, /opt is
:normally shared among hosts with the same architecture, like /usr;
:there's no place for machine-specific package directory structures.
:
:It's clearly an error for file storage to determine the API. Dozens of
:programs, and countless user scripts, broke when /usr/spool/mail moved
:to /var/spool/mail. Hundreds of installation scripts broke when /usr/man
:moved to /usr/share/man. Sun figured out its mistake by the time it
:introduced kernel-specific file sharing---notice the symlink from
:/usr/sbin/adb to /usr/kvm/adb---but we're still stuck with / and /usr
:and /usr/share. It's particularly depressing that all this complexity is
:visible on single-user machines that don't share any files.
:
:I'd like to see a standard place for package directories, independent of
:file storage. The obvious name is /package: e.g., /package/lprng, with
:programs in /package/lprng/bin and data in /package/lprng/spool.
:
:Of course, packages are constantly upgraded, and you shouldn't have to
:remove the old version of a package to try out the new version. So
:/package/lprng is actually a symlink to /package/lprng-3.7.2. The
:upgrade script moves data from lprng/spool to lprng-3.7.2/spool, stops
:the old lprng, switches the symlink, and starts the new lprng.
:
:On systems that share files, the package manager can automatically set
:up appropriate symlinks, using some system-specific configuration and a
:small amount of sharing information included in the package:
:
: /package/lprng-3.7.2/src -> /shared/dist/lprng-3.7.2/src
: /package/lprng-3.7.2/bin -> /shared/syst/openbsd-i386/lprng-3.7.2/bin
:
:But the only program that cares about this is the package manager; and
:systems without file sharing don't need /shared at all.
:
:I mentioned this design on the FHS list a couple of years ago, and set
:up a mailing list for it (send mail to [EMAIL PROTECTED]),
:but not many people were interested. Bummer.
:
:---Dan
:
