Skip Navigation Links | |
Exit Print View | |
Packaging and Delivering Software With the Image Packaging System in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
1. IPS Design Goals, Concepts, and Terminology
2. Packaging Software With IPS
Creating and Publishing a Package
Add Necessary Metadata to the Generated Manifest
Add Any Facets or Actuators That Are Needed
Publish to a Local File Repository
Using Package Repositories and Archives
Converting SVR4 Packages To IPS Packages
Generate an IPS Package Manifest from a SVR4 Package
Other Package Conversion Considerations
3. Installing, Removing, and Updating Software Packages
4. Specifying Package Dependencies
6. Modifying Package Manifests Programmatically
7. Automating System Change as Part of Package Installation
8. Advanced Topics For Package Updating
Many of the criteria for good package development described in this section require you to make trade-offs. Satisfying all requirements equally is often difficult. The following criteria are presented in order of importance. However, this sequence is meant to serve as a flexible guide depending on your circumstances. Although each of these criteria is important, it is up to you to optimize these requirements to produce a good set of packages.
Oracle Solaris uses a hierarchical naming strategy for IPS packages. Wherever possible, design your package names to fit into the same scheme. Try to keep the last part of your package name unique so that users can specify a short package name to commands such as pkg install.
Consider the various patterns of software use (client and server) when laying out packages. Good package design divides the affected files to optimize installation of each configuration type. For example, for a network protocol implementation, the package user should be able to install the client without necessarily installing the server. If client and server share implementation components, create a base package that contains the shared bits.
Packages should be self-contained and distinctly identified with a set of functionality. For example, a package that contains ZFS should contain all ZFS utilities and be limited to only ZFS binaries.
Packages should be organized from a user's point of view into functional units.
Put code that requires royalty payments due to contractual agreements or that has distinct software license terms in a dedicated package or group of packages. Do not disperse the code into more packages than necessary.
Packages that overlap cannot be installed at the same time. An example of packages that overlap are packages that deliver different content to the same file system location. Since this error might not be caught until the user attempts to install the package, overlapping packages can provide a poor user experience. The pkglint(1) tool can help to detect this error during the package authoring process.
If the package content must differ, declare an exclude dependency so that IPS does not allow these packages to be installed together.
A package represents a single unit of software, and is either installed or not installed. (See the discussion of facets in Optional Software Components to understand how a package can deliver optional software components.) Packages that are always installed together should be combined. Since IPS downloads only changed files on update, even large packages update quickly if change is limited.