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.
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.
If you are designing a package for a Solaris 2.5 or compatible release, you should consider the various types of system software configurations (for example, standalone, diskless, 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 dataless and server configurations can easily be supported.
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.
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.
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, SPARCTM binaries would be in one package and binaries for an x86 system would be in another.
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.
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.