Application Packaging Developer's Guide

Chapter 1 Designing a Package

Before you build a package, you need to know which files you need to create and the commands you need to execute. You also need to consider your application software's requirements and the needs of your customers. Your customers are the administrators who will be installing your package. This chapter discusses the files, commands, and criteria you should know and consider before building a package.

This is a list of the information in this chapter.

Where to Find Packaging Tasks

Use these task maps to find step-by-step instructions for building and verifying packages.

What Are Packages?

Application software is delivered in units called packages. A package is a collection of files and directories that are required for a software product. A package is usually designed and built by the application developer after completing the development of the application code. A software product needs to be built into one or more packages so that it can easily be transferred to a distribution medium. Then, the software product can be mass produced and installed by administrators.

A package is a collection of files and directories in a defined format. This format conforms to the application binary interface (ABI), which is a supplement to the System V Interface Definition.

Package Components

The components of a package fall into two categories.

The control files are also divided into two categories: information files and installation scripts. Some control files are required. Some control files are optional.

To package your applications, you must first create the required components, and any optional components, that make up your package. You can then build the package by using the pkgmk command.

To build a package, you must provide the following:

The following figure describes the contents of a package.

Figure 1–1 The Contents of a Package

The preceding context and the following context describe
the graphic.

Required Package Components

You must create the following components before you build your package:

Optional Package Components

Package Information Files

You can include four optional package information files in your package:

Each package information file should have an entry in the prototype file. See Creating Information Files for more information on creating these files.

Package Installation Scripts

Installation scripts are not required. However, you can provide scripts that perform customized actions during the installation of your package. An installation script has the following characteristics:

The four script types are as follows:

See Creating Installation Scripts for a more information on installation scripts.

Considerations Before Building a Package

Before building a package, you need to decide whether your product will consist of one or more packages. Note that many small packages take longer to install than one big package. Although creating a single package is a good idea, doing so is not always possible. If you decide to build more than one package, you need to determine how to segment the application code. This section provides a list of criteria to use when planning to build a package.

Many of the packaging criteria present trade-offs among themselves. Satisfying all requirements equally is often difficult. These criteria are presented in order of importance. However, this sequence is meant to serve as a flexible guide depending on the circumstances. Although each criterion is important, it is up to you to optimize these requirements to produce a good set of packages.

For more design ideas, see Chapter 6, Advanced Techniques for Creating Packages.

Make Packages Remotely Installable

All packages must be remotely installable. Being remotely installable means that the administrator installing your package might be trying to install it on a client system, not necessarily to the root (/) file system where the pkgadd command is being executed.

Optimize for Client-Server Configurations

Consider the various types of system software configurations (for example, standalone system and server) when laying out packages. Good packaging design divides the affected files to optimize installation of each configuration type. For example, the contents of the root (/) and /usr file systems should be segmented so that server configurations can easily be supported.

Package by Functional Boundaries

Packages should be self-contained and distinctly identified with a set of functionality. For example, a package that contains UFS should contain all UFS utilities and be limited to only UFS binaries.

Packages should be organized from a customer's point of view into functional units.

Package Along Royalty Boundaries

Put code that requires royalty payments due to contractual agreements in a dedicated package or group of packages. Do not disperse the code into more packages than necessary.

Package by System Dependencies

Keep system-dependent binaries in dedicated packages. For example, the kernel code should be in a dedicated package, with each implementation architecture consisting of a distinct package instance. This rule also applies to binaries for different architectures. For example, binaries for a SPARC system would be in one package and binaries for an x86 system would be in another package.

Eliminate Overlap in Packages

When constructing packages, eliminate duplicate files whenever possible. Unnecessary duplication of files results in support and version difficulties. If your product has multiple packages, repeatedly compare the contents of these packages for duplicated files.

Package Along Localization Boundaries

Localization-specific items should be in their own package. An ideal packaging model would have a product's localizations delivered as one package per locale. Unfortunately, in some cases organizational boundaries conflict with the functional and product boundaries criteria.

International defaults can also be delivered in a package. This design isolates the files that are necessary for localization changes and standardizes the delivery format of localization packages.

Image Packaging System (IPS) Packages

This document discusses SVR4 packages. For delivery into the OpenSolaris OS, consider using Image Packaging System (IPS) packages. The OpenSolaris OS supports both SVR4 and IPS packages. The IPS software interacts with network repositories and uses the ZFS file system. In the OpenSolaris OS, you can publish existing SVR4 packages to an IPS repository with the pkgsend(1) command.

The following table contains a comparison of commands for the SVR4 packaging system and the IPS packaging system. For detailed information on IPS, see Getting Started With the Image Packaging System.

Table 1–1 Packaging Tasks: IPS and SVR4


IPS command 

SVR4 command 

Install a new package 

pkg install

pkgadd -a

Display information about a package's state 

pkg list


Verify correct installation of a package 

pkg verify

pkgchk -v

Display information about a package 

pkg info

pkginfo -l

Listing the contents of a package 

pkg contents

pkgchk -l

Uninstall a package 

pkg uninstall


Packaging Commands, Files, and Scripts

This section describes the commands, files, and scripts that you might use when manipulating packages. They are described in man pages and in detail throughout this book, in relation to the specific task they perform.

The following table shows the commands to help you build, verify, install, and obtain information about a package.

Table 1–2 Packaging Commands


Command/ man Page 


For More Information 

Create packages 


Generates a prototype file for input to the pkgmk command

Example—Creating a prototype File With the pkgproto Command


Creates an installable package 

Building a Package


Install, remove, and transfer packages 


Installs a software package onto a system 

Installing Software Packages


Stores answers to a request script

Design Rules for request Scripts



Copies packages onto a distribution medium 

Transferring a Package to a Distribution Medium



Removes a package from a system 

Removing a Package


Obtain information about packages 


Verifies the integrity of a software package 

Verifying the Integrity of a Package


Displays software package information 

The pkginfo Command



Displays package parameter values 

The pkgparam Command


Modify installed packages 


Incorporates a new package object into an already installed package 

Design Rules for Procedure Scripts and Chapter 5, Case Studies of Package Creation


Removes a package object from an already installed package 

Design Rules for Procedure Scripts


The following table shows the information files that help you build a package.

Table 1–3 Package Information Files



For More Information 


Package installation defaults file 

The Administrative Defaults File


Package compatibility file 

Defining Package Dependencies


Package copyright information file 

Writing a Copyright Message


Package dependencies file 

Defining Package Dependencies


Package characteristics file 

Creating a pkginfo File


Package contents description file 

The pkgmap File


Package information file 

Creating a prototype File


Package disk space requirements file 

Reserving Additional Space on a Target System

The following table describes optional installation scripts that you can write that affect if and how a package is installed.

Table 1–4 Package Installation Scripts



For More Information 


Solicits information from the installer 

Writing a request Script


Gathers file system data 

Gathering File System Data With the checkinstall Script


Performs any custom installation requirements before class installation 

Writing Procedure Scripts


Performs any custom installation requirements after all volumes are installed 

Writing Procedure Scripts


Performs any custom removal requirements before class removal 

Writing Procedure Scripts


Performs any custom removal requirements after all classes have been removed 

Writing Procedure Scripts

Class action 

Performs a series of actions on a specific group of objects 

Writing Class Action Scripts