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.
