Print-friendly Version

Introduction to Package Components for the Solaris OS

Surender Samant, November 2006

Software for the Solaris Operating System is delivered in a format known as SVR4 packages. The Solaris OS consists of a set of such packages, each of which is a bundle of executable files, configuration files, meta-information files, and scripts. These packages provide a means for getting software on and off a system, repeatedly.

A software product can be defined as a group of files that, when installed, provide a service of some value. The method used for distributing and installing software products on a host that will provide access to these products is called packaging.

Providing complex software such as the Solaris OS as a set of packages has advantages like the following:

• The Solaris OS can be divided into many different packages, each of which can be installed and removed as a unit.
• Automation is made easier.
• Dependencies and incompatibilities can be checked.
• Some tasks can be executed before installation or after removal of such packages.
• Patches can be applied and removed reliably.

In short, packaging provides facilities such as product integrity, product validation, and install/remove facility.

Figure 1
(Click to Enlarge)

A sample Solaris package is shown in the figure above.

Each Solaris package is represented as a directory that has the same name as the package. The package contains many files and directories out of which only pkginfo and pkgmap are mandatory. All other items shown in the figure are optional.

The pkginfo and pkgmap files are meta-information files. The pkginfo file acts like a label on a box. It contains information such as name, identifier, build date, who to contact if there's a problem, and so on.

The pkgmap file is a packing list, where each item in the package is defined and its size and checksum are stored. The size and checksum help in determining that the package has not been tampered with. The various items in the pkgmap are recognized by their ftype entry as shown here.

When a package is installed (using pkgadd), first directories (d), devices (c/b), and symlinks (s) are created. Then the files of type f, e, or v are copied into the file system. Hard links (ftype l) are created after all the other files have been installed. The install meta-files (ftype i) are used to direct the installation and removal of software and are not installed on the system.

A Solaris package typically contains reloc and install directories. The reloc directory contains all the files that are to be installed relative to a base directory, i.e. it contains the relocatable files. An optional root directory contains files that are to be installed relative to the root directory. Another optional directory called archive may also be present, which contains general-purpose files whose functions are defined by the package developer. The install directory contains scripts and other auxiliary files. All files of ftype i except pkginfo and pkgmap go into install.

The install directory contains a copyright file, an optional depend file, and scripts like checkinstall, preinstall, postinstall, preremove, and postremove. This directory may also contain a set of some special scripts known as Class Action Scripts. All the meta-info files are Bourne shell scripts.

The checkinstall script performs a detailed analysis of the system and gathers data; it doesn't change anything on a file system. The script may create or alter environment variables to control the installation. The script can cleanly halt the package installation, if necessary.

preinstall runs just before the actual file installation begins. This script is involved in things such as initializing the prototype and meta-files for the backout package, which will be constructed later by the postinstall script.

If a package is removed (using pkgrm), the preremove and postremove scripts, if present, run before and after the removal of the package to do some tasks like deleting the contents of some directories.

All the objects in a package fall under some class that is defined during package creation. If an object doesn't fall under any class, none class is used by default. All the classes to be installed are listed in the parameter CLASSES, which is defined in the pkginfo file. The installation occurs in the order they are listed in pkginfo. Objects with class none are always installed first. So none, if present in pkginfo, is always the first class entry. If a class isn't listed in the pkginfo, the objects in that class won't get installed even if they are defined in pkgmap.

Class Action Scripts (CAS) redefine how to add or remove an object from the package. That is, instead of a simple copy of files from the package to the appropriate file system, CAS may allow merging entries with an existing file, or saving a copy of an existing file. The Class Action Scripts work similarly during removal of a package. The install and removal Class Action Scripts are named i.<class> and r.<class>, respectively, for <class>. Files with ftype e and v are expected to have Class Action Scripts.

All the dependencies that a package might have on other packages are listed in the depend file.

As mentioned previously, pkginfo and pkgmap are the only required files in a package. One can create a package with just these two files. Such a package is perfectly acceptable, though it doesn't provide any important functionality per se.

Solaris packages can also be delivered in Package Datastream format. In this format there is a file containing one or more packages. This file is different from the directory format explained previously, which had one directory containing a package. Package datastreams are easier to distribute. We can convert from one format to another using pkgtrans.

Let's look at an example that shows how to collect information about an installed package. Here's how to find out the name of the package that contains truss utility:

# pkgchk -lp /usr/bin/truss 
Pathname: /usr/bin/truss
Type: linked file
Source of link: ../../usr/lib/isaexec
Referenced by the following packages:
        SUNWtoo
Current status: installed

The output for the preceding command shows that truss is in the package SUNWtoo. Let's get some information about this package:

# pkginfo -l SUNWtoo
   PKGINST:  SUNWtoo
      NAME  :  Programming Tools
  CATEGORY:  system
      ARCH   :  sparc
   VERSION:  11.10.0,REV=2005.01.21.15.53
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  utilities for software development, including ld, ldd, od, and truss
    PSTAMP:  on10-patch20060622130233
  INSTDATE:  Sep 07 2006 14:10
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed
     FILES:       66 installed pathnames
                  11 shared pathnames
                   3 linked files
                  15 directories
                  30 executables
                1993 blocks used (approx)

Additional Resources

More detailed information about packages can be found in the Application Packaging Developer's Guide.

About the Author

Surender Samant works in Solaris sustaining engineering at Sun Microsystems, Inc. He has worked in approachability areas such as patching/packaging, install, and Solaris Zones. He has a Masters of Technology degree in Computer Science and Engineering from the Indian Institute of Technology in Guwahati.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.