Everything is under /opt/csw

That's the number 1 rule of filesystem layout right there: everything goes under /opt/csw. The reason for this is to simplify read-only NFS sharing of /opt/csw to multiple systems, and to simplify management in general.

The exceptions to this would be when some program is typically configured to be machine-specific in all cases. (ie: where NFS_sharing the configuration files doesnt make sense). For those types of packages, the SVR4 filesystem standard suggests that /etc/opt/csw/[softwarename] be used as a configuration directory (although clearly labeled examples may go in /opt/csw/etc).

Contrariwise, a program should ONLY write to /opt/csw/var, if it is presumed to never be run from a read-only /opt/csw. In other words, for programs that it only makes sense to have installed locally. Otherwise, it is better to use /var/opt/csw/[softwarename] for a 'var' type purposes.
It is possible, however, for sysadmin admins to mount a writable local /opt/csw/var, on top of a read-only /opt/csw, so the problem may not be fatal. But for the general case, /opt/csw/var is preferred.

General layout philosophy

Generally speaking, we will use a typical free software /usr/local style layout. Substitute /opt/csw in place of /usr/local, and everything should look "normal". In fact, if you make a symbolic link from /usr/local to /opt/csw, or lofs mount, etcetera, things should generally work as expected if you set your PATH to include /usr/local/bin

Subdirectories of /opt/csw

bin

User runnable executables

bin/sparcv8plus

32-bit executables optimized for sparc "v8+" instruction set. Should have its RPATH set to use libs in /opt/csw/lib/sparcv8plus.

bin/sparcv8plus+vis

32-bit executables optimized for sparc "v8+" instruction set, with use of the VIS extensions to the SPARC instruction set. Should have its RPATH set to use libs in /opt/csw/lib/sparcv8plus+vis. This is probably more useful than sparcv8plus, since all sun ultrasparcs support this sub-architecture.

bin/sparcv9

64-bit executables for sparc, if isaexec is used in bin. Should have its RPATH set to use libs in /opt/csw/lib/sparcv9.

etc

Configuration files

lib

"library" files, and other architecture dependant files. Typically used for "libxxx.so" files. May also be used in some cases for datafiles for a program (would normally be stored under lib/progname/). However, the preferred location for non-library data would normally be under the 'share' directory.

lib/locale

localized information that has been compiled to arch-specific formats, belongs in here.

lib/32

A symbolic link back to the lib directory.

lib/64

Points to 64-bit versions of shared libraries found in lib directory, if available

lib/sparcv8plus

For libraries optimized for 32 ultrasparc cpus that have the "v8+" SPARC instruction set

lib/sparcv8plus+vis

For libraries optimized for 32 ultrasparc cpus that have the "v8+" SPARC instruction set AND the VIS extensions.

lib/sparcv9

Typically where lib/64 will point to, on sparc systems.

lib/X11

The equivalent of /usr/openwin/lib/X11, or /usr/X11R6/lib/X11. Note that "app-defaults" files go under lib/X11/app-defaults

libexec

[Definition under construction]

Tentative definition: Location for executables that are run only by other programs, not by a person at a command line prompt.

sbin

Executables for sysadmins to run (includes demons)

share

Data that is shared by multiple programs. Or, common areas that hold certain types of data. Or, a datafile storage area for programs (eg: share/progname/datafiles.txt). Things in here should be architecture-neutral (non-endian-dependant, pure data type stuff, usually textfiles, documentation, etc.)

share/man

manpages go under here

share/doc

Non man-page and non "info" documentation goes here. For example, /opt/csw/share/doc/yourprog/README. A README file here is a good place to put additional user instructions on configuration of complex packages

share/java

"pure java" jarfile packages should be kept here.

var

Data that varies with the running of a program. Typically, programs will have their own subdirectory of var.

[programname]

Sometimes, when a program has an extreme amount of subprograms, utilities, and libraries associated with it, it may warrant its own subtree under /opt/csw. Generally, programs that expect to install themselves under their own /usr/local/[programname]/ tree, would be installed in /opt/csw/[programname]/

Perl module locations

Please make a note that we take advantage of perl's "vendor" options, to maintain our own "csw" directories, as a vendor of perl packages.

      Good locations for perl modules:
        /opt/csw/lib/perl/csw
        /opt/csw/share/perl/csw
      Bad locations for perl modules:
        /opt/csw/lib/perl/site_perl
        /opt/csw/share/perl/site_perl
      

The easy way to trigger install to these locations, depends on whether the software in question provides Makefile.PL or Build.PL. Choose the appropriate line from either of the following:

      perl Makefile.PL INSTALLDIRS=vendor  #DESTDIR=xxx
      # or
      perl Build.PL installdirs=vendor  #destdir=xxx
      

Hacks

Note that the CSWcommon package currently provides certain links for directories:

 man  -> share/man
 doc  -> share/doc
 info -> share/info
 

This is to make it easier to do a "make install ; find /opt/csw |pkgproto" cycle and have the results come out "correct", even if the software normally installs things into $prefix/man, and so on. Do not put /opt/csw/{man|info|doc} into your pkg prototype files

[Content of this page maintained by Phil Brown]