OpenCSW - Open Community Software

Standards for building CSW packages

This section of web pages, relates to how to CREATE a package for CSW. Users of our packages probably wont care about these pages, other than perhaps to feel glad that all this work is done for them!

New maintainers, please go to the New maintainers welcome page, and/or the simple package walkthrough page

This page is a guide for making a package for submission to the Solaris CSW packaging effort at, by someone who has officially signed up to be "a maintainer".

Note: No alpha, beta, or otherwise unstable software will be accepted to the archives.

The overriding guideline is to provide a straightforward, easy-to-use experience for the user. For a fuller view of the principles behind CSW, see the core principles page.

The user should generally be able to do

 pkg-get install xyz
and have xyz just work, with no extra fuss.

Anyone can suggest changes to these documents. However, changes championed by active maintainers will get the most attention. If you would like to see some of these items changed, it is suggested you either volunteer to be a maintainer, or forward your proposed changes to an active maintainer.

Software Configuration standards

All packages will be configured to deliver binaries "ready to run", as judged by professional sysadmin standards. No by-hand steps should be needed. For example, CSWossh has rc scripts that automatically build ssh host keys, if needed.

Exceptions to this rule are only if the software needs fundamental by-hand configuration to do anything useful.
Example: mysql, a database program

In these cases, the package should provide either an install script, or sample configuration files, or both.

Extra documentation should go under /opt/csw/share/doc/programname

Tools in /opt/csw/*bin should not conflict with programs of the same name in OS-standard locations such as /usr/bin. If the tool is one of the standard GNU-style 'replacements', it can usually be configured/compiled with --program-prefix=g . This will prefix all executables with a 'g' (eg: "make" becomes "gmake", etc). This allows users to know which version of a program they are getting, reguardless of what order their PATH is set to.
On the other hand, if a program's normal name does not conflict, [such as 'bison'], then using adding an 'g' to GNU programs is not neccessary. Similarly, if what is in /opt/csw/bin is a newer version of what is shipped in /bin (such as 'bash') then prefixing is not neccesary.

Build standards

Our standard compiler is the sun compiler(s), which should be used in preference to gcc, unless the software only compiles with gcc. Builds will be done on both Solaris 8 x86 and Solaris 8 sparc, unless there is need for a Solaris-9 specific binary also.

More details on build standards, cpu optimizations, package filenames, and package versions, are now on the separate Build standards page

Demon configuration standards

[This section is still potentially in flux]
If a user choses to pkg-get a demon, it should be assumed that in the general case, they want it to be auto-configured and run, if it is straightforward to do so.

The exception to this, is if site administrators do not wish demons to be auto-configured. To this end, a new configuration file, csw.conf has been designated, that postinstall scripts should check before deciding to auto-enable demons or services.

Shared library tips and pitfalls

If you are building a package that contains a shared library, you should read our standards page for shared library packaging tips

Filesystem layout standards

  • Keep your stuff under "/opt/csw" !
  • Dont conflict with other peoples' packages
  • Default ownership of files to root:bin
  • Install the 'common' CSW pkg first, so you get any links that need to be installed, installed.
A lengthier set of details can be found on the filesystem layout page. Everyone building a package should read it at least once.

Security updates for packages

The handling of security updates for software is a tricky thing, that tends to be somewhat dependant on the specific software being packaged. There are some small software packages, with very responsible authors, who from time to time have an emergency security update that is 100% reliable, and should be packaged the same day it is released.

In contrast, there are some large software packages, whose authors are infamous for never getting a security update right the first time. In this case, rushing out security update packages for those pieces of software, is a waste of time for the most part, and can actually cause more harm than good.

A package maintainer is assumed to be reasonably familiar with the history of the software they are packaging. They should ideally be the best person to judge which category their software package falls under, and release appropriately.

Pkg file creation

Mechanics and policies of SysV pkg creation are in our package creation page(s). Anyone who would like to know how to make packages, should read the link to learn more.

Once you have created your pkg file, dont forget to run checkpkg on it.
"checkpkg" can be found in cswutils. If you use "createpkg" from cswutils to create the package,it will automatically run checkpkg for you.

As mentioned on the bottom of the simple package walkthrough page, completed packages should be copied to, after which, you need to email Phil to say you are officially all done.
(A more streamlined process is planned for the future.)

SMF and Solaris 10

If you are interested in making your packages integrate with Solaris 10's SMF framework, see our SMF package integration page

Signing up

Still up to the task of making a CSW package? Then please let us know!

[Content of this page maintained by Phil Brown]