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
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