IPS is designed to eliminate some long-standing issues with previous software distribution, installation, and maintenance mechanisms that have caused significant problems for Oracle Solaris customers, developers, maintainers, and ISVs.
Principle IPS design goals include:
Minimize planned downtime by making software update possible while systems are in production.
Minimize unplanned downtime by supporting quick reboot to known working software configurations.
Automate, as much as possible, the installation of new software and updates to existing software.
Resolve the difficulties with ever-increasing software size and limited distribution media space.
Ensure that it is possible to determine whether a package is correctly installed as defined by the author (publisher) of the package. Such a check should not be spoofable.
Incorporate mechanisms to allow for the easy virtualization of Oracle Solaris at a variety of levels, in particular using zones.
Reduce the effort required to generate patches or upgrades for existing systems.
Enable other software publishers (ISVs and end-users themselves) to easily create and publish packages for Oracle Solaris.
These goals led to the following ideas:
Leverage ZFS snapshot and clone facilities to dynamically create boot environments on an as-needed basis.
Since Oracle Solaris 11 requires ZFS as the root file system, zone file systems need to be on ZFS as well.
Users can create as many boot environments as desired.
IPS can automatically create boot environments on an as-needed basis, either for backup purposes prior to modifying the running system, or for installation of a new version of the OS.
Eliminate duplicated mechanisms and code used to install, patch, and update.
This idea results in several significant changes to the way Oracle Solaris is maintained, including the following important examples:
All OS software updates and patching are done directly with IPS.
Any time a new package is installed, it is already exactly at the correct version.
The requirement for unspoofable verification of package installation has the following consequences:
If a package needs to support installation in multiple ways, those ways must be specified by the developer so that the verification process can take this into account.
Scripting is inherently unverifiable since the packaging system cannot determine the intent of the script writer. This, along with other issues discussed later, led to the elimination of scripting during packaging operations.
A package cannot have any mechanism to edit its own manifest, since verification is then impossible.
If the administrator wants to install a package in a manner incompatible with the original publisher's definition, the packaging system should enable the administrator to easily republish the package he wants to alter so that the scope of his changes is clear, not lost across upgrades, and can be verified in the same manner as the original package.
The need to avoid size restrictions led to a software repository model, accessed using several different methods. Different repository sources can be composited to provide a complete set of packages, and repositories can be distributed as a single file. In this manner, no single media is ever required to contain all the available software. To support disconnected or firewalled operations, tools are provided to copy and merge repositories.
The desire to enable multiple (possibly competing) software publishers led to the decision to store all the packaging metadata in the packages themselves: No master database exists for information such as all packages and dependencies. A catalog of available packages from a software publisher is part of the repository for performance reasons, but the catalog can also be regenerated from the data contained in the packages.