add directory docs

docs/linux-standards/fsstnd/old/ChangeLog-1.1-to-1.2

@@ -0,0 +1,39 @@
+Here is a list of the major specification changes from FSSTND 1.1 to
+FSSTND 1.2.  Since this is a simplification, it's a good idea to check
+out the standard document itself if one of these changes concerns you or
+your software.
+
+    * /bin: tcsh may be in /bin/tcsh or /usr/bin/tcsh.  (It was
+    previously implied that /bin/tcsh was not compliant.)
+
+    * /dev: the Linux device registrar is now H. Peter Anvin
+    <Peter.Anvin@linux.org>, see the up-to-date device list at
+    ftp.yggdrasil.com in /pub/device-list.
+
+    * /etc: subdirectories of /etc/X11 for each window manager are no
+    longer required.
+
+    * /lib: /lib may contain miscellaneous shared libraries for binaries
+    required in /bin or /sbin.  (As was the case before, but it's
+    spelled-out now.)
+
+    * /lib: /lib/modules is included, but not fully specified.
+
+    * /sbin: `ctrlaltdel' is optional.
+
+    * /usr: clarify that /usr/X386 is X11R5 on i386, /usr/X11R6 is X11R6
+    on any Linux system.
+
+    * /usr/include: /usr/include/g++ is now required.
+
+    * /var/adm is obsolete.  lastlog is now in /var/log/lastlog.  wtmp
+    is now in /var/log/utmp.  utmp is now in /var/run/utmp.
+    Transitional symbolic links: /var/adm to /var/log, /var/log/utmp to
+    /var/run/utmp.
+
+    * /var/catman: /usr/man/cat[1-9] is for preformatted (i.e., on a
+    CD-ROM) manual pages.  /var/catman remains a writable cache of
+    formatted manual pages.
+
+    * /var/named has been clarified, especially in relationship to
+    /etc/named.boot.

docs/linux-standards/fsstnd/old/FSSTND-FAQ

@@ -0,0 +1,259 @@
+This is a collection of Frequently Asked Questions (and answers!)
+about the Linux FSSTND project and document.  It was composed by Ian
+McCloghrie <ian@ucsd.edu>.  Questions, corrections, clarifications,
+etc. about this FAQ should be directed to him.
+
+Sun Oct  9 22:55:25 PDT 1994
+
+Note:  This FAQ is wrtten by me, personally, as an attempt to help out
+the FSSTND project.  This FAQ reflects my personal views and, while I
+am a member of the FSSTND project, should not be construed as
+necessarily reflecting the views of everyone on the project.
+
+
+========= General Questions ==========
+
+
+Q)  Who wrote the FSSTND, and where can I get in contact with them?
+
+A)  The FSSTND is a consensus effort of many Linux activists; the main
+arm of their discussion takes place on the FSSTND mailing list.
+The principal co-ordinator is Daniel Quinlan <Daniel.Quinaln@linux.org>
+Any questions you may have regarding the standard should be directed
+to him or to any of the contributors listed in the FSSTND document or
+this FAQ.
+
+The FSSTND discussion mailing list is "linux-fsstnd@ucsd.edu"; if you
+wish to participate in future expansion of the standard, you can
+subscribe to this list by sending mail to "listserv@ucsd.edu", with the
+body of "add linux-fsstnd".
+
+
+Q)  What's the current status of the FSSTND?
+
+A)  As of this writing, (Oct 9, 1994), Linux FSSTND 1.2 has been
+released as an interim draft, and is available for anonymous FTP
+from tsx-11.mit.edu in /pub/linux/docs/linux-standards/fsstnd.
+PostScript, dvi, and ascii text versions are available.
+
+Due to the fact that a significant number of Linux developers are
+making use of standard drafts that came after the first version (back
+in February), the decision was made to issue an interim version in
+order to ensure that everyone is working from the same foundation.
+
+
+Q)  Why 'FSSTND' anyway?  That's a horrible abbreviation.
+
+A)  Yes, 'FSSTND' is a horrible abbreviation of "Filesystem Standard".
+Unfortunately, that's the name that was given to the initial channel
+of the niksula.hut.fi mailing list, and it's kinda stuck.  Changing it
+would create more confusion than it's really worth.
+
+
+Q)  I've got a great new idea for how to organize the filesystem;
+why don't we...
+
+A)  If you really think you've got something revolutionary, by all
+means, we'd love to see it.  In practice, a lot of "great new" ideas
+have been raised (and dropped, for one reason or another) on the
+mailing list already.  As such, we suggest you send mail to one of the
+contributors privately first, and get his/her reaction to it, before
+making a general proposal.
+
+
+Q)  Why did you do it *THIS* way?  Why not do what Sun did and...
+
+A)  The FSSTND draws ideas from POSIX, 4.4BSD, SVR4, SunOS 4, MCC,
+Slackware, SLS, (in no particular order) and many other systems.  We
+have not followed any one operating system layout in entirety.
+Instead we have tried to take the best of each filesystem layout and
+combine them into a homogenous whole, well suited to the needs of
+Linux users everywhere.  In some cases, we may not have been
+completely successful; however, we think we've done a fairly decent
+job.
+
+
+Q)  You *&^% idiots, don't you know that foo goes in /bin, not in /usr/bin?
+
+A)  Think about it.  Does foo *really* need to go on the root
+partition?  Constructive suggestions are welcomed.  Flames are not.
+
+We have tried to decide upon a set of binaries that is an effective
+compromised between functionality and space restrictions.  The root
+partition needs to contain enough functionality to boot the system,
+mount the /usr partition, and to enable a systems administrator to
+repair things on /usr if something goes wrong.  If you have a local
+boot-time system that absolutely requires other binaries to be used
+in the mounting of /usr, the suggested solution is to move them to
+/bin and to make a symbolic link from /usr/bin/foo to /bin/foo.
+
+
+Q)  Does the fact that Daniel Quinlan now works for Yggdrasil affect
+his coordination of the FSSTND?
+
+A)  In short, no.  In a bit more length, no, except for the fact that
+he's now even more intimately familiar with the problems involved
+in creating a distribution.  (well, and that he's earning money and
+can afford to buy food to eat, so has energy to spare worrying about
+things like which directory cpio belongs in)
+
+FSSTND is not distribution-specific, the fact that the coordinator is
+employed by one distribution-provider does not affect this fact.  Yggdrasil
+does not have any special connection to FSSTND, and vice versa.
+To simplify things, Dan would appreciate it if you could direct FSSTND-
+related email to <Daniel.Quinlan@linux.org>.
+
+
+========== Specific Questions ==========
+
+
+Q)  The distinction between the root partition and /usr is that the
+root is used for files that are 'essential'.  What constitutes
+'essential'?
+
+A)  essential to clean, create, prepare, check, find and mount other
+filesystems (possibly on remote machines).  There are other definitions,
+but this is a general definition that most people will at least
+incorporate into their own.
+
+
+Q)  I like to have a small root partition (possibly with multiple
+copies, so I can get the system back up when one of them crashes),
+and I like to stuff everything else into one big partition (especially
+since I only have one free).  So, can /var be a symlink to /usr?
+
+A)  Making the /var hierarchy a part of a /usr filesystem is
+preferable to making /var a part of the root filesystem when /var
+cannot be made a separate partition.
+
+This is preferable because it is easier to separate /var and /usr
+at some point in the future, if you buy a second disk.  The usual way
+of doing this to make /var a symblink link to /usr/var.
+
+
+Q)  Why is networking spread out across the filesystem in 4 separate
+directories instead of all being nicely put in /usr/inet?
+
+A)  It is the opinion of the FSSTND project (and, in fact, of much of
+the UNIX community in general) that networking is not an "optional
+package" in the traditional sense, but rather an integrated part oF
+the operating system.  Binaries such as telnet, ftp, and ping have
+more similiarity to standard unix utilities such as grep, sed, and vi
+than to applications like emacs or WordStar.  As such, they are
+spread across /bin, /sbin, /usr/bin, and /usr/sbin, depending upon
+their use.
+
+
+Q)  I'm running a HUGE network with 10 different platforms and 20
+different OS's.  I *need* to share things.  Why isn't there a
+/usr/share?
+
+A)  At the moment, Linux is only really available for the
+PC-architecture 80386 machines.  (although this may change soon with
+Amiga systems).  There is no single existing "cross-platform" standard
+for /usr/share; those that do exist have usually been come up with by
+a single vendor wanting to share certain files between their OS
+running on multiple hardware platforms.  There are many problems
+involved in the sharing of files, maybe obvious sharable files that
+are, upon closer examination, not sharable at all.  (For example,
+/usr/man could be thought completely sharable, yet some pages (such as
+fsck.1) are completely different from any other UNIX-like operating
+system).
+
+/usr/share would be nice, yes, and we plan to include something like
+this in a future version of the FSSTND.  However, until such a time
+as an implementation can actually be tested, no specifications will be
+released.  Anything in /usr/share will be "pointed to" by the use of
+symlinks from other areas in the filesystem, such as /usr/man,
+/usr/lib/<something>, etc.  Applications should use these locations
+when they reference files, not the /usr/share location, as this may
+change.  Things like OSI have shown the problems with standards
+specified without a real clue as to how they'd be implemented.
+
+
+Q)  Why are there so many/so few symbolic links in the filesytem?
+Couldn't we make it easier to understand/more orthogonal by
+removing/adding some links?
+
+A)  In general, we've tried to minimize the number of symbolic links
+present in the FSSTND.  The symlinks that are present in the document
+are the ones we considered essential to maintaining a properly
+orthogonal, and yet still somewhat compatible, filesystem layout.
+/lib/cpp and /usr/lib/sendmail are symbolic links kept for
+compatiblity reasons.
+
+
+Q)  What about statically linked binaries?  Shouldn't we have a
+statically linked copy of mount, unmount, sh, cp, mv, vi, emacs, gcc,
+X11R5, and WABI in /sbin?
+
+A)  Statically linked binaries are a local issue.  Most users, those
+with home systems with small amounts of memory and disk and a single
+user on console, do not have any need for any statically linked
+binaries (with the possible exception of ln, sync, and/or ldconfig, to
+fix shared library problems).  Some larger sites, with more disk to
+spare, may wish to install backup, statically-linked versions of some
+applications.  If you have the need and space to do this, go right
+ahead, we're not stopping you.  But we don't require any, because
+(we feel) that most people don't need them.  Dynamically linked
+versions should still be available, for regular usage, however.
+
+
+Q)  Why does X11 get its own directory tree when there aren't any
+other such "packages" in the FSSTND?  Why not spread it out over
+/usr/bin/X11, /usr/lib/X11, etc.
+
+A)  X11 is just about the largest 'package' in common use on Linux
+systems.  It resides in /usr/X386 as this is the directory name choice
+of the XFree86 developers, to protect against namespace conflicts with
+other X11 packages on any of the dozen or so PC-unix platforms they
+support.  The symbolic links in /usr/bin/X11, /usr/lib/X11 and
+/usr/include/X11 are for user's convenience, these are the closest
+things that exist to "standard" locations for the X11 files.
+
+
+Q)  Why isn't there a package format laid out in the FSSTND?
+
+A)  Many proposals have been discussed for package layouts on the
+fsstnd mailing list.  As yet, no consensus has been reached about
+which (if any) of these proposals is best.  Work continues, and there
+will probably be mention of 'packages' in version 1.1.
+
+
+Q)  What about /usr/local/bin/X11?  Should I use this for local X11
+programs?  Or is /usr/local/X11/bin better?
+
+A)  The standard doesn't specify; we feel that the contents of /usr/local
+are exactly that, local, and so we try to specify as little as
+possible about it.  Put them wherever you want.  Personally, I use
+/usr/local/bin/X11.  However, since xmkmf doesn't seem to like placing
+files into anywhere other than where the existing X files are
+(ie, /usr/X386/*), my libs for local apps usually end up being in
+/usr/X386.  Ugly, yes, but not worth (to me) the effort of trying to
+move them.  Your mileage may vary.
+
+
+Q)  Why doesn't the standard specify the system-level users/groups and
+proper ownerships/permissions/setuid bits for everything?
+
+A)  We feel that this is, primarily, a local issue.  Many sites
+have their own local user-id/group-id setup, and linux boxes will
+have to be integrated with those.  What's more, there is very little
+gain from standardizing these across all linux machines, as it
+typically is not essential to allow binary distributions.
+
+
+Q)  Why not just symlink /bin to /usr/bin the way Sun, SVR4, and a few
+others do?
+
+A)  This has several technical problems, aside from the fact that many
+consider it ugly.  First, it requires placing all the utilites necessary
+to mount /usr into /sbin, and either making copies of them in /usr/bin
+or having every user put /sbin into their $PATH.  Second, if /lib is
+symlinked to /usr/lib in the same way, it requires statically linking
+all the binaries in /sbin.  This results in /sbin taking up more space
+on the root partition, for a great reduction in functionality, thus
+increasing the number of cases in which one has to go dig out a
+boot/root floppy instead of just booting the hard disk in single-user
+mode.
+

docs/linux-standards/fsstnd/old/fsstnd-1.0/FSSTND-FAQ

@@ -0,0 +1,239 @@
+This is a collection of Frequently Asked Questions (and answers!)
+about the Linux FSSTND project and document.  It was composed by Ian
+McCloghrie <ian@ucsd.edu>.  Questions, corrections, clarifications,
+etc. about this FAQ should be directed to him.
+
+Mon Mar 14 13:56:28 PST 1994
+
+Note:  This FAQ is wrtten by me, personally, as an attempt to help out
+the FSSTND project.  This FAQ reflects my personal views and, while I
+am a member of the FSSTND project, should not be construed as
+necessarily reflecting the views of everyone on the project.
+
+========= General Questions ==========
+
+Q)  Who wrote the FSSTND, and where can I get in contact with them?
+
+A)  The FSSTND is a consensus effort of many Linux activists; the main
+arm of their discussion takes place on the FSSTND mailing list.
+The principal co-ordinator is Daniel Quinlan <quinlan@bucknell.edu>.
+Any questions you may have regarding the standard should be directed
+to him or to any of the contributors listed in the FSSTND document or
+this FAQ.
+
+The FSSTND discussion mailing list is "linux-fsstnd@ucsd.edu"; if you
+wish to participate in future expansion of the standard, you can
+subscribe to this list by sending mail to "listserv@ucsd.edu", with the
+body of "add linux-fsstnd".
+
+
+Q)  What's the current status of the FSSTND?
+
+A)  As of this writing, (Feb 21, 1994), Linux FSSTND 1.0 has been
+released, and is available for anonymous FTP from tsx-11.mit.edu
+in /pub/linux/docs/linux-standards/fsstnd PostScript, dvi, and ascii
+text versions are available.
+
+The release of 1.0 does not mean that work on FSSTND has stopped,
+however.  We are still discussing issues that were not deemed
+essential enough to be worth holding up the release of 1.0.
+
+
+Q)  Why 'FSSTND' anyway?  That's a horrible abbreviation.
+
+A)  Yes, 'FSSTND' is a horrible abbreviation of "Filesystem Standard".
+Unfortunately, that's the name that was given to the initial channel
+of the niksula.hut.fi mailing list, and it's kinda stuck.  Changing it
+would create more confusion than it's really worth.
+
+
+Q)  I've got a great new idea for how to organize the filesystem;
+why don't we...
+
+A)  If you really think you've got something revolutionary, by all
+means, we'd love to see it.  In practice, a lot of "great new" ideas
+have been raised (and dropped, for one reason or another) on the
+mailing list already.  As such, we suggest you send mail to one of the
+contributors privately first, and get his/her reaction to it, before
+making a general proposal.
+
+
+Q)  Why did you do it *THIS* way?  Why not do what Sun did and...
+
+A)  The FSSTND draws ideas from POSIX, 4.4BSD, SVR4, SunOS 4, MCC,
+Slackware, SLS, (in no particular order) and many other systems.  We
+have not followed any one operating system layout in entirety.
+Instead we have tried to take the best of each filesystem layout and
+combine them into a homogenous whole, well suited to the needs of
+Linux users everywhere.  In some cases, we may not have been
+completely successful; however, we think we've done a fairly decent
+job.
+
+
+Q)  You *&^% idiots, don't you know that foo goes in /bin, not in /usr/bin?
+
+A)  Think about it.  Does foo *really* need to go on the root
+partition?  Constructive suggestions are welcomed.  Flames are not.
+
+We have tried to decide upon a set of binaries that is an effective
+compromised between functionality and space restrictions.  The root
+partition needs to contain enough functionality to boot the system,
+mount the /usr partition, and to enable a systems administrator to
+repair things on /usr if something goes wrong.  If you have a local
+boot-time system that absolutely requires other binaries to be used
+in the mounting of /usr, the suggested solution is to move them to
+/bin and to make a symbolic link from /usr/bin/foo to /bin/foo.
+
+
+========== Specific Questions ==========
+
+
+Q)  The distinction between the root partition and /usr is that the
+root is used for files that are 'essential'.  What constitutes
+'essential'?
+
+A)  essential to clean, create, prepare, check, find and mount other
+filesystems (possibly on remote machines).  There are other definitions,
+but this is a general definition that most people will at least
+incorporate into their own.
+
+
+Q)  Why is networking spread out across the filesystem in 4 separate
+directories instead of all being nicely put in /usr/inet?
+
+A)  It is the opinion of the FSSTND project (and, in fact, of much of
+the UNIX community in general) that networking is not an "optional
+package" in the traditional sense, but rather an integrated part oF
+the operating system.  Binaries such as telnet, ftp, and ping have
+more similiarity to standard unix utilities such as grep, sed, and vi
+than to applications like emacs or WordStar.  As such, they are
+spread across /bin, /sbin, /usr/bin, and /usr/sbin, depending upon
+their use.
+
+
+Q)  I'm running a HUGE network with 10 different platforms and 20
+different OS's.  I *need* to share things.  Why isn't there a
+/usr/share?
+
+A)  At the moment, Linux is only really available for the
+PC-architecture 80386 machines.  (although this may change soon with
+Amiga systems).  There is no single existing "cross-platform" standard
+for /usr/share; those that do exist have usually been come up with by
+a single vendor wanting to share certain files between their OS
+running on multiple hardware platforms.  There are many problems
+involved in the sharing of files, maybe obvious sharable files that
+are, upon closer examination, not sharable at all.  (For example,
+/usr/man could be thought completely sharable, yet some pages (such as
+fsck.1) are completely different from any other UNIX-like operating
+system).
+
+/usr/share would be nice, yes, and we plan to include something like
+this in a future version of the FSSTND.  However, until such a time
+as an implementation can actually be tested, no specifications will be
+released.  Anything in /usr/share will be "pointed to" by the use of
+symlinks from other areas in the filesystem, such as /usr/man,
+/usr/lib/<something>, etc.  Applications should use these locations
+when they reference files, not the /usr/share location, as this may
+change.  Things like OSI have shown the problems with standards
+specified without a real clue as to how they'd be implemented.
+
+
+Q)  Why are there so many/so few symbolic links in the filesytem?
+Couldn't we make it easier to understand/more orthogonal by
+removing/adding some links?
+
+A)  In general, we've tried to minimize the number of symbolic links
+present in the FSSTND.  The symlinks that are present in the document
+are the ones we considered essential to maintaining a properly
+orthogonal, and yet still somewhat compatible, filesystem layout.
+/lib/cpp and /usr/lib/sendmail are symbolic links kept for
+compatiblity reasons.
+
+
+Q)  What about statically linked binaries?  Shouldn't we have a
+statically linked copy of mount, unmount, sh, cp, mv, vi, emacs, gcc,
+X11R5, and WABI in /sbin?
+
+A)  Statically linked binaries are a local issue.  Most users, those
+with home systems with small amounts of memory and disk and a single
+user on console, do not have any need for any statically linked
+binaries (with the possible exception of ln, sync, and/or ldconfig, to
+fix shared library problems).  Some larger sites, with more disk to
+spare, may wish to install backup, statically-linked versions of some
+applications.  If you have the need and space to do this, go right
+ahead, we're not stopping you.  But we don't require any, because
+(we feel) that most people don't need them.  Dynamically linked
+versions should still be available, for regular usage, however.
+
+
+Q)  Why does X11 get its own directory tree when there aren't any
+other such "packages" in the FSSTND?  Why not spread it out over
+/usr/bin/X11, /usr/lib/X11, etc.
+
+A)  X11 is just about the largest 'package' in common use on Linux
+systems.  It resides in /usr/X386 as this is the directory name choice
+of the XFree86 developers, to protect against namespace conflicts with
+other X11 packages on any of the dozen or so PC-unix platforms they
+support.  The symbolic links in /usr/bin/X11, /usr/lib/X11 and
+/usr/include/X11 are for user's convenience, these are the closest
+things that exist to "standard" locations for the X11 files.
+
+
+Q)  Why aren't the locations of home directories required in the standard?
+
+A)  On many linux systems, all home directories exist as
+/home/<username>.  This is fine for small home systems (and is what I,
+personally, would recommend for such a system).  For larger systems,
+where the number of users exceeds 50 or so, or in an NFS-environment,
+where different people have home directories on different machines,
+all cross-mounted, a simple scheme like this is woefully inadequate,
+and something more complex is required.  (As a side note, in such
+situations, automounter programs (like amd) are quite useful.)
+Applications should consult the password file (or $HOME) to determine
+a user's home directory, and not rely on a direct path.
+
+
+Q)  Why isn't there a package format laid out in the FSSTND?
+
+A)  Many proposals have been discussed for package layouts on the
+fsstnd mailing list.  As yet, no consensus has been reached about
+which (if any) of these proposals is best.  Work continues, and there
+will probably be mention of 'packages' in version 1.1.
+
+
+Q)  What about /usr/local/bin/X11?  Should I use this for local X11
+programs?  Or is /usr/local/X11/bin better?
+
+A)  The standard doesn't specify; we feel that the contents of /usr/local
+are exactly that, local, and so we try to specify as little as
+possible about it.  Put them wherever you want.  Personally, I use
+/usr/local/bin/X11.  However, since xmkmf doesn't seem to like placing
+files into anywhere other than where the existing X files are
+(ie, /usr/X386/*), my libs for local apps usually end up being in
+/usr/X386.  Ugly, yes, but not worth (to me) the effort of trying to
+move them.  Your mileage may vary.
+
+
+Q)  Why doesn't the standard specify the system-level users/groups and
+proper ownerships/permissions/setuid bits for everything?
+
+A)  We feel that this is, primarily, a local issue.  Many sites
+have their own local user-id/group-id setup, and linux boxes will
+have to be integrated with those.  What's more, there is very little
+gain from standardizing these across all linux machines, as it
+typically is not essential to allow binary distributions.
+
+
+Q)  Why not just symlink /bin to /usr/bin the way Sun, SVR4, and a few
+others do?
+
+A)  This has several technical problems, aside from the fact that many
+consider it ugly.  First, it requires placing all the utilites necessary
+to mount /usr into /sbin, and either making copies of them in /usr/bin
+or having every user put /sbin into their $PATH.  Second, if /lib is
+symlinked to /usr/lib in the same way, it requires statically linking
+all the binaries in /sbin.  This results in /sbin taking up more space
+on the root partition, for a great reduction in functionality, thus
+increasing the number of cases in which one has to go dig out a
+boot/root floppy instead of just booting the hard disk in single-user
+mode.

docs/linux-standards/fsstnd/old/tentative-opt-draft

@@ -0,0 +1,121 @@
+Proposed /opt addition to the FSSTND.
+
+------------------------------------------------------------------------
+
+/etc/opt -- Machine-specific configuration files for /opt
+
+Machine-specific configuration files for add-on application software
+packages shall be installed within the directory /etc/opt/<package>,
+where <package> is the name of the subtree in /opt where the static
+data from that package is stored.  No structure is imposed on the
+internal arrangement of /etc/opt/<package>.
+
+If a configuration file must reside in a different location in order
+for the package or system to function properly, it may be placed in a
+location other than /etc/opt/<package>.
+
+------------------------------------------------------------------------
+
+/opt -- Add-on application software packages
+|
++-bin       Executable files invoked directly by users
++-man       Package manual pages
++-<package> Static package objects
+
+/opt is reserved for the installation of add-on application software
+packages.
+
+A package to be installed in /opt shall install its static files in a
+separate /opt/<package> directory tree, where <package> is the name of
+the software package.  The possible exceptions are user-executable
+files and user-readable manual pages (accessed via `man'), which may
+optionally be installed in /opt/bin and /opt/man, respectively.
+
+User-executable files that are not installed in the /opt/bin directory
+shall be installed in the directory /opt/<package>/bin.
+
+User-readable manual pages that are not installed in the /opt/man
+directory tree shall be installed in /opt/<package>/man.  /opt/man
+shall have the same substructure as /usr/man.  If /opt/<package>/man
+is present, the same substructure as /usr/man shall be used.
+
+Package files that are variable (change in normal operation) should be
+installed in /var/opt.  See the section on /var/opt for more
+information.
+
+Machine-specific configuration files should be installed in /etc/opt.
+See the section on /etc for more information.
+
+No other package files should exist outside the /opt, /var/opt, and
+/etc/opt hierarchies except for those package files that must reside
+in specific locations within the filesystem tree in order to function
+properly.  For example, device lock files must be placed in /var/lock
+and devices must be located in /dev.
+
+------------------------------------------------------------------------
+
+/var/opt -- Variable data for /opt
+
+Variable data should be installed in /var/opt/<package>, where
+<package> is the name of the subtree in /opt where the static data
+from an add-on software package is stored, except where superseded by
+another file in /etc.  No structure is imposed on the internal
+arrangement of /var/opt/<package>.
+
+------------------------------------------------------------------------
+
+* Reference:
+
+These extracts are taken from "System V Application Binary Interface"
+[ (c) 1990 AT&T ] and is based on System C Interface Definition, Third
+Edition.  This books contains the guidelines for System V Release 4.0
+and as such are probably "current".
+
+Thanks to Stephen Harris <sweh@spuddy.mew.co.uk> for posting the
+excerpts.
+
++++++
+
+Page 2-16 "File tree for add-on software"
+
+/opt, /var/opt and /etc/opt are reserved in the file tree for the installation
+of application software packages.  Each add-on software package should adhere
+to the following rules:
+
+ o Static package objects should be installed in /opt/pkg, where pkg is the
+   package abberviation or instance.
+
+ o Package objects that change in normal operations (for example, log and
+   spool files) should be installed in /var/opt/pkg.
+
+ o machine-specific configuration files should be installed in /etc/opt/pkg
+
+ o Executables that are directly invoked by users should be installed in
+   /opt/pkg/bin
+
+ o Only package objects that must reside in specific locations within the
+   system file tree in order to function properly (for example, special
+   files in /dev) should be installed in those locations.
+
+------
+
+Further on page 9-4 of the "System V ABI" we find
+
++++++
+
+The /opt subtree
+
+The directoy /opt of the / file system is the point of access to the /opt
+subtree.  This directory subtree contains files installed by add-on
+packages.
+
+The following describes the structure of the /opt subtree:
+
+/opt          The top directory of the /opt subtree
+
+/opt/bin      Executable files provided by application packages and
+              invoked directly by users
+
+/opt/pkg       Where pkg is the abbreviated name of an add-on software
+               package, contains all the static files installed on the
+               system as part of that package