OpenSolaris

  subsites:   Code Reviews   Gates   Issues   Defects   Polls   Test   PKG   Planet   Mail
You are not signed in. Sign in or register.

Solaris Package Companion

The Solaris Package Companion is a small Korn shell script that allows you to ask quite a number of interesting questions about the relationships between Solaris metaclusters, clusters and packages as well as their respective dependencies. Very often, answers to these kinds of questions are essential for the construction of minimized systems as well as more generally for OS golden images.

The goal of the Solaris Package Companion, or SPC for short, is to do all of the hard work so you don't have to. SPC will create a cache of important facts by mining information from the various packaging files and directories to allow you to quickly and easily obtain answers to a variety of questions such as:

  • What clusters or packages are contained in a given metacluster?
  • What packages are contained in a given cluster?
  • What metacluster or cluster contains a given package?
  • On what other packages does a given package or cluster depend?
  • Which packages depend on a given package?
  • … and so on…

Note that this tool is provided to the community for its use, but it is not officially supported by Sun.

Downloading the Tool

The current version of the Solaris Package Companion is v0.8.1. The MD5 fingerprint for this file is: 

 $ digest -v -a md5 ./spc-v0.8.1.ksh
 md5 (./spc-v0.8.1.ksh) = 7bf5831685562b62dce1cc0304b3d720

Special thanks to Clive King for pointing out a bug in the recently released 0.8 version related to the processing of local system package information. This bug has been fixed in version 0.8.1 and no other changes were introduced in this release.

Thanks also to Peter Pickford (for pointing out a case where not all package dependencies were being captured) and Fredrich Maney (for contributing the new tree display options). In addition to these enhancements, a little code cleanup was also incorporated into this release.

An older version of the tool is available in case there are any problems with the current version. The MD5 fingerprint for version 0.7 is:

 blackhole$ digest -v -a md5 ./spc-v0.7.ksh
 md5 (./spc-v0.7.ksh) = 43e6cb9359a5aefa607a0ce67cfe5b67

The information below assumes that you are using the latest version of the tool.

Installing the Tool

The Solaris Package Companion is just a single shell script and can be installed into any directory location. Permissions typically should be:

$ ls -l spc-v0.8.ksh
-rwxr-xr-x   1 gbrunett staff      24841 Aug  1 14:55 spc-v0.8.ksh

Using the Tool

The following is the list of options supported by the Solaris Package Companion:

$ ./spc-v0.8.ksh -h
General Options:
   -F           [fold packages into their respect clusters – experimental]
   -h, -?       [show help]
   -l           [local mode – use local system repositories and data]
   -r           [repository location]
   -s           [solaris distribution location]
   -v           [show package details]
Processing Options:
   To initialize the information repository used by this tool.
      -i (used with either the -s or -l options)
   To display the list of packages contained in the specified cluster(s).
      -c <package cluster list>
   To display the metacluster(s) that contain the specified cluster(s).
      -C <package cluster list>
   To display the dependencies for the specified package(s).
      -d <package list>
   To display the dependencies for the specified cluster(s).
      -D <package cluster list>
   To evaluate install packages on a system against a specified metacluster.
      -e <metacluster>
   To determine what package contains a given file (experimental).
      -f <file name> (fully qualified path names only)
   To display the packages contained in the specified metacluster(s).
      -m <metacluster list>
   To display the clusters contained in the specified metacluster(s).
      -M <metacluster list>
   To display the cluster that contains the specified package(s).
      -p <package list>
   To display the metacluster(s) that contain the specified package(s).
      -P <package list>
   To display a tree view of the specified cluster(s) (experimental).
      -t <cluster list>
   To display a tree view of the specified metacluster(s) (experimental).
      -T <metacluster list>
   To display the list of packages that depend on the specified package(s).
      -z <package list>
   To display the list of packages that depend on the specified cluster(s).
      -Z <package cluster list>

Before you can use the tool for the first time, you must create its package information cache. By default, the information cache contains information regarding packaging relationships, dependencies, names and even which files are contained within each package. Collecting this amount of information can generate a cache of over 30M and take several minutes to complete. If you are sure you do not need this much information, you can adjust one of the COLLECT_ variables inside of the program. The smallest cache (with no names, dependencies, or package maps) is roughly 4MB. In general, it is recommended that the settings remain unmodified so that the complete set of functionality is enabled. This is also why no public interface has been provided to adjust these settings. Note that the repository need only be created once (for each distribution you want to inspect) so the impact should be minimal both in terms of time and disk space.

The information cache can be created in one of two ways depending on what you would like to accomplish. First, if you would like to create a cache based on Solaris installation media, then you should use the following command:

 $ ./spc-v0.8.ksh -i -s /media/SOL11X86/Solaris_11/Product -r ./myrepository

This will create a cache based on the Solaris OS media found at the location specified by the -r option. On the other hand, if you wanted to create a cache based upon the local system, you can use the following command:

 $ ./spc-v0.8.ksh -i -l -r ./myrepository

In this case, it leverages information found on the currently installed system to create its cache (stored in ./myrepository). Note that since each cache is specified by name, there is nothing to stop you from having multiple caches for different systems, versions of the operating system, etc.

The time to create the cache will vary depending on the media being read as well as the performance of the system on which it is being created. Initial testing showed that the time could range from 10 to 30 minutes. Once the cache is created, it will not need to be created nor modified again so this is a one time penalty as noted above.

Examples

The following are just a few examples to illustrate how the SPC tool can be used to answer some very interesting packaging questions. We would love to hear about other uses and requirements in this space, so please forward your ideas and feedback along!

Each of these examples was generated using the most recent version of the tool against a Solaris 10 05/08 (Update 5, build 10) repository. Each of these examples should work with other versions of the Solaris OS including newer Nevada builds.

What packages are in cluster SUNWCssh?

$ ./spc-v0.8.ksh -r ./myrepository -c SUNWCssh
SUNWsshcu
SUNWsshdr
SUNWsshdu
SUNWsshr
SUNWsshu

In addition, you can always get more information by specifying the -v option:

$ ./spc-v0.8.ksh -v -r ./myrepository -c SUNWCssh
[P] SUNWsshcu                 SSH Common, (Usr)
[P] SUNWsshdr                 SSH Server, (Root)
[P] SUNWsshdu                 SSH Server, (Usr)
[P] SUNWsshr                  SSH Client and utilities, (Root)
[P] SUNWsshu                  SSH Client and utilities, (Usr)

Updated in this release is the tag before the item name to inform the user of the type of object being dispayed. [P] indicates a package while [C] is a cluster and [M] is a metacluster. In previous releases this was placed between the item name and item description.

Also new in this release is the ability to display information in a tree view.

What packages are in cluster SUNCssh (tree view)?

$ ./spc-v0.8.ksh -v -r ./myrepository -t SUNWCssh
   [C] SUNWCssh                  Secure Shell
      [P] SUNWsshcu                 SSH Common, (Usr)
      [P] SUNWsshdr                 SSH Server, (Root)
      [P] SUNWsshdu                 SSH Server, (Usr)
      [P] SUNWsshr                  SSH Client and utilities, (Root)
      [P] SUNWsshu                  SSH Client and utilities, (Usr)

Similar questions can be asked of metaclusters as well:

$ ./spc-v0.8.ksh -v -r ./myrepository -T SUNWCmreq | head -10
[M] SUNWCmreq                 Minimal Core System Support
   [C] SUNWCfca                  Sun ISP Fibre Channel Device Drivers
      [P] SUNWqlc                   Qlogic ISP 2200/2202 Fibre Channel Device Driver
      [P] SUNWemlxs                 Emulex-Sun LightPulse Fibre Channel Adapter (FCA) driver (root)
   [C] SUNWCfct                  Sun Fibre Channel Transport Software
      [P] SUNWfcsm                  FCSM driver
      [P] SUNWfctl                  Sun Fibre Channel Transport layer
      [P] SUNWfcp                   Sun FCP SCSI Device Driver
      [P] SUNWfcip                  Sun FCIP IP/ARP over FibreChannel Device Driver
   [C] SUNWCfmd                  Fault Management Daemon and Utilities
[…]

Thanks to Fredrich Maney for contributing code to implement these functions.

In what metaclusters is the SUNWsshdr package found?

$ ./spc-v0.8.ksh -v -r ./myrepository -P SUNWsshdr
[M] SUNWCall                  Entire Distribution
[M] SUNWCprog                 Developer System Support
[M] SUNWCuser                 End User System Support
[M] SUNWCXall                 Entire Distribution plus OEM support

On what packages does the SUNWsshdu package depend?

$ ./spc-v0.8.ksh -v -r ./myrepository -d SUNWsshdu
[P] SUNWcakr                  Core Solaris Kernel Architecture (Root)
[P] SUNWcar                   Core Architecture, (Root)
[P] SUNWckr                   Core Solaris Kernel (Root)
[P] SUNWcnetr                 Core Solaris Network Infrastructure (Root)
[P] SUNWcsd                   Core Solaris Devices
[P] SUNWcsl                   Core Solaris, (Shared Libs)
[P] SUNWcsr                   Core Solaris, (Root)
[P] SUNWcsu                   Core Solaris, (Usr)
[P] SUNWgss                   GSSAPI V2
[P] SUNWgssc                  GSSAPI CONFIG V2
[P] SUNWkvm                   Core Architecture, (Kvm)
[P] SUNWopenssl-libraries     OpenSSL Libraries (Usr)
[P] SUNWsshcu                 SSH Common, (Usr)
[P] SUNWsshdr                 SSH Server, (Root)
[P] SUNWzlib                  The Zip compression library

Another new feature is the ability to fold packages back into their respective clusters (where possible). This can be helpful when trying to create a complete list of items for a standard OE image or JumpStart configuration. This can be accomplished using the '-F' (folding) option:

$ ./spc-v0.8.ksh -v -r ./myrepository -d -F SUNWsshdu
[P] SUNWcakr                  Core Solaris Kernel Architecture (Root)
[P] SUNWcar                   Core Architecture, (Root)
[C] SUNWCcs                   Core Solaris
[C] SUNWCfwcmp                Freeware Compression Utilities
[C] SUNWCopenssl              OpenSSL
[C] SUNWCssh                  Secure Shell
[P] SUNWgss                   GSSAPI V2
[P] SUNWgssc                  GSSAPI CONFIG V2
[P] SUNWkvm                   Core Architecture, (Kvm)

In this case, several of the packages were able to be folded into their respective clusters leaving just a handful of individual packages. These packages do not belong to any existing software cluster.

Which package contains the file /usr/sbin/zic?

$ ./spc-v0.8.ksh -r ./myrepository -l -v -f /usr/sbin/zic
[P] SUNWcsu                   Core Solaris, (Usr)

Which package cluster contains the file /usr/sfw/lib/libcrypto.so?

$ ./spc-v0.8.ksh -r ./myrepository -l -F -v -f /usr/sfw/lib/libcrypto.so
[C] SUNWCopenssl              OpenSSL

Which packages depend on the SUNWmfrun package?

 blackhole$ pkginfo SUNWmfrun
 system      SUNWmfrun Motif RunTime Kit
$ ./spc-v0.8.ksh -v -r ./myrepository -z SUNWmfrun | head -10
[P] IPLTadcon                 Administration Server Console
[P] IPLTadmin                 Administration Server
[P] IPLTcadcon                Administration Server Console Simplified Chinese Localization
[P] IPLTcadmin                Administration Server Simplified Chinese Localization
[P] IPLTccons                 Console Client Base Simplified Chinese Localization
[P] IPLTcdscon                Directory Server Console Simplified Chinese Localization
[P] IPLTcdsu                  Directory Server (usr) Simplified Chinese Localization
[P] IPLTcons                  Console Client Base
[P] IPLTdscon                 Directory Server Console
[P] IPLTdsr                   Directory Server (root)

This option can also take advantage of the folding (-F) option to merge packages back into their respective clusters (if applicable):

$ ./spc-v0.8.ksh -v -F -r ./myrepository -z SUNWmfrun | grep "[C]"
[C] SUNWCappserver            Sun Java(tm) System Application Server
[C] SUNWCbrowser              SUNWCbrowser
[C] SUNWCbrowserdev           SUNWCbrowserdev
[C] SUNWCdhcp                 DHCPv4 Services
[C] SUNWCdtdev                CDE Developer Software
[C] SUNWCdtrun                CDE Runtime Software
[C] SUNWCdtts                 Solaris Trusted Extensions CDE
[C] SUNWCdtusr                CDE End User Software
[C] SUNWCevo                  Evolution
[C] SUNWCevodev               Evolution Developer Packages
…

Testing the Tool

After some reworking, I have also released version 0.1 of the Solaris Package Companion Testing Tool, spc-test-v0.1.sh. This tool is fairly configurable, allowing you to test multiple versions of the tool against multiple repositories. There are currently 48 tests although tests can be easily added or removed as needed. It can optionally display the results to the screen, but by default it records them in a directory where a basic consistency check is performed to detect differences in output (for the same repository) resulting from the use of different versions of the tool. This is not intended to be an all encompassing test suite, but rather a basic sanity check to make sure the key functions are working as expected.

Project Lead(s)

Acknowledgements

  • David Comay
  • Clive King
  • Fredrich Maney
  • Peter Pickford

Additional References