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.
