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.
It is composed of Bourne shell commands.
Its file permissions should be set to 0644.
It does not need to contain the shell identifier (#! /bin/sh).
The four script types are as follows:
The request script
The request script requests input from the administrator installing the package.
The checkinstall script
The checkinstall script performs special file system verification.
Note - The checkinstall script is only available with the Solaris™ 2.5 and compatible releases.
Procedure scripts
Procedure scripts define actions that occur at particular points during package installation and removal. There are four procedure scripts you can create with these predefined names: preinstall, postinstall, preremove, and postremove.
Class Action scripts
Class Action scripts define a set of actions to be performed on a group of objects.
See "Creating Installation Scripts" for a more information on installation scripts.
Things to Think About Before Building a Package
Before building a package, you need to decide whether your product is going to be made up of one or more packages. (Note that many small packages take longer to install than one big package.) Although it is a good idea to create a single package, it 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 packages.
Many of the good packaging criteria present trade-offs among themselves. It will often be difficult to satisfy all requirements equally. 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 of these criteria 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 Package Creation Techniques.
Make Packages Installable Remotely
All packages must be installable remotely. Being installable remotely 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 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 root (/) and usr 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 containing 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 corresponding to a distinct package instance. This rule also applies to binaries for different architectures. For example, binaries for SPARC™ based system would be in one package and binaries for an IA based system would be in another.
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 redundancies.
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 may conflict with the functional and product boundaries criteria.
International defaults can also be delivered in a package. This would isolate the files necessary for localization changes and standardize delivery format of localization packages.
Packaging Commands, Files, and Scripts
The purpose of this section is to describe the commands, files, and scripts 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 table below shows the commands available to help you build, verify, install, and obtain information about a package.
Table 1-1 Packaging Commands
Function | Command | Description | For More Information, Go To ... |
|---|---|---|---|
Create packages | pkgproto(1) | Generate a prototype file for input to the pkgmk command | |
pkgmk(1) | Create an installable package | ||
Install, remove, and transfer packages | pkgadd(1M) | Install a software package onto a system | |
pkgask(1M) | Store answers to a request script | ||
pkgtrans(1) | Copy packages onto a distribution medium | ||
pkgrm(1M) | Remove a package from a system | ||
Obtain information about packages | pkgchk(1M) | Check consistency of a software package | |
pkginfo(1) | Display software package information | ||
pkgparam(1) | Display package parameter values | ||
Modify installed packages | installf(1M) | Incorporate a new package object into an already installed package | "Design Rules for Procedure Scripts" and Chapter 5, Package Creation Case Studies |
removef(1M) | Remove a package object from an already installed package |
The table below shows the information files available to help you build a package.
Table 1-2 Package Information Files
Files | Description | For More Information, Go To ... |
|---|---|---|
admin(4) | Package installation defaults file | |
compver(4) | Package compatibility file | |
copyright(4) | Package copyright information file | |
depend(4) | Package dependencies file | |
pkginfo(4) | Package characteristics file | |
pkgmap(4) | Package contents description file | |
prototype(4) | Package information file | |
space(4) | Package disk space requirements file |
The table below describes optional installation scripts that you can write that affect if and how a package is installed.
Table 1-3 Package Installation Scripts
Scripts | Description | For More Information, Go To ... |
|---|---|---|
request | Solicit information from the installer. | |
checkinstall | Gather file system data. | |
preinstall | Perform any custom installation requirements before class installation. | |
postinstall | Perform any custom installation requirements after all volumes are installed. | |
preremove | Perform any custom removal requirements before class removal. | |
postremove | Perform any custom removal requirements after all classes have been removed. | |
Class Action | Perform a series of actions on a specific group of objects. |