This section provides high-level descriptions of each state in the IPS package lifecycle. For best results, both package developers and system administrators should understand the various phases of the package lifecycle.
Packages can be created by anyone. IPS does not impose any particular software build system or directory hierarchy on package authors. For details about package creation, see Packaging Software With IPS. Aspects of package creation are discussed throughout the remaining chapters of this guide.
Packages are published to an IPS repository, either to an HTTP location or to the file system. A published package can also be converted to a .p5p package archive file. To access software from an IPS repository, the repository can be added to the system using the pkg set-publisher command, or the repository can be accessed as a temporary source by using the -g option with pkg commands. Examples of package publication are shown in Packaging Software With IPS.
Packages can be installed on a system, either from an IPS repository accessed over http://, https://, or file:// URLs, or from a .p5p package archive. Package installation is described in more detail in Installing, Removing, and Updating Software Packages.
Updated versions of packages might become available, either published to an IPS repository, or delivered as a new .p5p package archive. Installed packages can then be brought up to date, either individually, or as part of an entire system update.
Note that IPS does not use the same concept of “patching” that the SVR4 packaging system did. All changes to IPS packaged software are delivered by updated packages.
Package updates are performed in much the same way as package installations, but the packaging system is optimized to install only the changed portions delivered by an updated package. Package updating is described in more detail in Installing, Removing, and Updating Software Packages.
During the life of a package, you might want to rename the package. A package might be renamed for organizational reasons or to refactor packages. Examples of package refactoring include combining several packages into a single package or breaking a single package into multiple smaller packages.
IPS gracefully handles content that moves between packages. IPS also allows old package names to persist on the system, automatically installing the new packages when a user asks to install a renamed package. Package renaming is described in more detail in Renaming, Merging, and Splitting Packages.
Eventually a package might reach the end of its life. A package publisher might decide that a package will no longer be supported, and that it will not have any more updates made available. IPS allows publishers to mark such packages as obsolete.
Obsolete packages can no longer be used as a target for most dependencies from other packages, and any packages upgraded to an obsolete version are automatically removed from the system. Package obsoletion is described in more detail in Renaming, Merging, and Splitting Packages.
Finally, a package can be removed from the system if no other packages have dependencies on it. Package removal is described in more detail in Installing, Removing, and Updating Software Packages.