|
New maintainers, 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 blastwave.org.
Efforts are focused on providing a greater, more timely set
of packages
than SFW, while also having consistency and dependancies that are not
offered by sunfreeware.com
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. The user should
generally be able to do
pkg-get install xyz
and have xyz just work, with no extra fuss. For a fuller view of the
principles behind CSW, see the core principles page.
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
Summary:
- 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.
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]
|
