I recently received a customer question regarding how they best could control which packages and which versions were used on their
production Solaris 11 servers. They had considered pointing each server at its own software repository - a common initial approach. A simpler method leverages one of dependency mechanisms we introduced with Solaris 11, but is not immediately obvious
to most people.
Typically, most internal IT departments qualify particular versions for
production use. What this customer wanted
to do was insure that their operations staff only installed internally qualified versions of Solaris on their servers. The easiest way of doing this is
to leverage the 'incorporate' type of dependency in a small package defined for each server type. From the reference " Packaging and Delivering Software With the Image Packaging System in Oracle® Solaris 11.1":
The incorporate dependency specifies that if the given package is installed, it must be at the given version,
to the given version accuracy. For example, if the dependent FMRI has a version of 1.4.3, then no version less than 1.4.3 or greater than or equal
to 1.4.4 satisfies the dependency. Version 1.4.3.7 does satisfy this example dependency. The common way
to use incorporate dependencies is
to put many of them in the same package
to define a surface in the package version space that is compatible. Packages that contain such sets of incorporate dependencies are often called incorporations. Incorporations are typically used
to define sets of software packages that are built together and are not separately versioned. The incorporate dependency is heavily used in Oracle Solaris
to ensurethat compatible versions of software are installed together. An example incorporate dependency is:
depend type=incorporate fmri=pkg:/driver/network/ethernet/
[email protected],5.11-0.175.0.0.0.2.1
So,
to make sure only qualified versions are installed on a server, create a package that will be installed on the machines
to be controlled. This package will contain an incorporate dependency on the "entire" package, which controls the various components used
to be build Solaris. Every time a new version of Solaris has been qualified for
production use, create a new version of this package specifying the new version of "entire" that was qualified. Once this new control package is available in the repositories configured on the
production server, the pkg update command will update that system
to the specified version. Unless a new version of the control package is made available, pkg update will report that no updates are available since no version of the control package can be installed that satisfies the incorporate constraint.
Note that if desired, the same package can be used
to specify which packages must be present on the system by adding either "require" or "group" dependencies; the latter permits removal of some of the packages, the former does not. More details on this can be found in either the section 5 pkg man page or the previously mentioned reference document.
This technique of using package dependencies
to constrain system configuration leverages the SAT solver which is at the heart of IPS, and is basic
to how we package Solaris itself.
