This page is a guide for users of CSW packages, to give you an idea of what to expect from our packages, and how best to use them.
First of all, you should expect to have a fairly painless experience using any CSW package. If any software does not install or setup in a reasonably straightforward manner, please file a bug report against the package.CSW packages are targetted at both end-users, and professional deployment. For the most part, they are suitable for deployment both locally, and on an NFS-shared filesystem. Packages usually install their software under
Some packages, however, do not make sense to deploy over NFS. Software that runs as a server demon, usually falls into this category (eg: mysql). It is assumed that servers will have packages installed locally, rather than over NFS. For this reason, server-targetted packages may install some files outside
/opt/csw. The usual reason for this is to install boot-time scripts in
/etc/rc*.d. They may also create service-oriented userids, if not already present on the system. (eg: user “mysql” for mysqld)
We strongly suggest that all users subscribe to the “announce” list, at http://lists.opencsw.org. This mailing list is for critical CSW related announcements only. “Announcements” about new packages of interest, go to the separate newpkgs list.
The easily browsable interface for our annouce list is at http://dir.gmane.org/gmane.os.solaris.opencsw.announce
For all our mailing lists, see further down this page.
Using programs in our packages
Most important of all, is to unset your
LD_LIBRARY_PATH variable. If you absolutely must have it set for some reason (not recommended), then best results should come if you use
# THIS IS NOT A GOOD IDEA LD_LIBRARY_PATH='/opt/csw/lib/$ISALIST':/other/values/here # THIS IS NOT A GOOD IDEA
The single-quotes are required, as is putting the csw entry FIRST.
All executables have been compiled with the appropriate -R flag, so that they will automatically use the right libraries by default.
LD_LIBRARY_PATH is a tool given to users so that they may choose to deliberately override the built-in library path of executables. If you choose to set
LD_LIBRARY_PATH, you have made a specific configuration choice that we cannot override in CSW packages. So if you use it, keeping things working is on your own shoulders.
Setting your PATH
Put /opt/csw/bin first in your path!! Particularly if you want to compile your own tools against CSW packages. Sun may also ship its own versions of things like
/bin/pkgconfig. If a configure script sees
/bin/pkgconfig first, then at best, you will miss out on features, and at worst, your compiled programs will crash mysteriously.Most binaries you care about, will be in
/opt/csw/bin . There are occasional packages that may have their own subdirectories – for example,
/opt/csw/apache . Generally speaking, however, you will only want to add
/opt/csw/bin to your
DO NOT add
/opt/csw/bin/sparcv9, or any other subdirectory of
/opt/csw/bin, to your
PATH. If there is a binary in
/opt/csw/bin/sparcv9, there will be an appropriate wrapper in
/opt/csw/bin of the same name, that will automatically determine whether to run the the sparcv8 version, or the sparcv9 version, of a program.
FYI: A good place to set the
PATH variable for everyone, is in
Setting your X resource search path
By default, Solaris programs tend to look in under
/usr/openwin/lib for what are called “app-default” customization files. Since we dont want to interfere with Solaris directories, we keep ours under
/opt/csw. To ensure you get all the CSW customizations, you should set the environment variable
XFILESEARCHPATH. We suggest the following setting:
XFILESEARCHPATH=/opt/csw/lib/X11/%T/%N%C:/usr/openwin/lib/X11/%T/%N%C export XFILESEARCHPATH
For long-time X users, please note that the old environment variable
XAPPLRESDIR is obsolete, and will not support the use of multiple directory names.
For more details on this variable, and resource files, please see http://www.faqs.org/faqs/x-faq/part2/section-22.html . The full documentation gives extra details on finer points such as making one that is flexible for your locale settings.
It is hoped that most people will take advantage of the features of install tools like
pkgutil to be able to simplify upgrading the CSW packages they have installed, with
As such, CSW packages are normally designed to cleanly go through a “
pkgrm CSWpkg ; pkgadd CSWpkg” cycle, without destroying any locally generated configuration. If you encounter software that does not cleanly handle an upgrade, please file a bug report against the package.
Sometimes, after upgrading a specific package individually, you may experience errors or problems with that package. Before assuming that that package is broken, please do a general
without limiting the upgrade to any one package, so that all your packages and libraries are brought up to the current version. This will often fix a perceived problem with a particular package.
Note to previous blastwave users
For those people who have currently installed our previous CSW packages when they were hosted by Blastwave,
pkgutil --upgrade will work for you with no problems. We kept our standard naming, so there is no problem for our users. Just change your
pkgutil.conf url to point to one of our mirror sites, and you will get the latest package goodness from us.
If you plan to migrate from Blastwave software stack to OpenCSW, a detailed how-to is available from this place.
Requesting updated software
If you notice that there is a newer version of software available from the original source code site, making a particular CSW package out of date, please file a bug report against the package. This is really the best way to let the maintainer know a newer version is available. It’s also a convenient way to let YOU know when the newer version gets packaged.
There are a few different places you can look for extra documentation or information on a program:
- In the directory
/opt/csw/share/doc/prognameFor simple programs, this directory may not exist. However, for more complex programs, more detailed instructions on configuration and usage may be found here.
- From the page
- Follow the link to the original source site, and browse around
- Click the button for “View News and Info”
Config files for most programs are either in
/etc/opt/csw. When a program always has a configuration unique to a machine, its configuration should always be under
/etc/opt/csw. However, in cases where the same software is commonly deployed across multiple machines, with a global configuration, then the configuration files may be in
/opt/csw/etc.Some programs that are flexible enough, will check first for a global configuration in
/opt/csw/etc, and then use a local one in
/etc/opt/csw as an override.
Relocation from /opt/csw
If for some reason, you cannot mount something in
/opt/csw directly, but must symlink
/opt/csw to somewhere else, you will probably want to set
in your environment. This is to avoid the system-level
/opt/csw into a real directory. However, the preferred method is to use a lofs mount, eg:
mount -F lofs /export/home/opt /opt/csw
Please note that it is not possible to completely relocate the software to elsewhere, and have /opt/csw not exist. Some programs require directory paths to be compiled into them, which means they will reference
Tips for large scale deployments
Sites that are interested in deploying CSW packages on a large scale, or sharing it across zones, will probably wish to read our page on sharing the /opt/csw filesystem
There are user-oriented mailing lists available, on lists.opencsw.org. Currently, there are lists available for general user questions, new package annoucements, and site announcements.
To sign up for a list, please go to – https://lists.opencsw.org/mailman/listinfo
To most easily browse, you may use the above url, or the somewhat easier archive site at http://dir.gmane.org/index.php?prefix=gmane.os.solaris.opencsw
Frequently asked questions
Please see the dedicated Frequently Asked Questions page.