Good things in packages

System V-based packages help ease your software installation and management.

To this day, software installation on Unix systems can be a Grand Adventure. More often than not you've got to use an arcane installation script that jerks along for hours, alternating between doing the installation and stopping to ask another endless stream of arcane configuration questions. Often I've thought, "If the installation software is any indication, I'm going to hate this application."

And if installation wasn't bad enough, wondering exactly where that software ended up on your system can haunt you and your computer for years to come. Many applications blithely install themselves into system directories like /bin and /etc, blissfully wiping out files of the same name that you may have already created. And because you rarely have a complete list of installed filenames and locations, it usually is next to impossible to remove an application once you've installed it.

Fortunately, with the advent of Solaris 2.x, SunSoft has made giant strides in formalizing the installation, removal, and management of software. They adopted the System V packaging model to provide standard mechanisms for installing, inventorying, validating, and removing any software package from initial OS installation to third-party tools and patch files.

A surprise inside
With that new Solaris facility, a single, installable software entity is called a package. Each package contains any number of files, executable scripts that dictate how to install and remove the files, and dependency lists that indicate which other packages, if any, the installed application might also need to properly operate. Packages and their scripts conform to a standard System V definition and come with all the tools you need to create, install, remove, and manage software.

The tool that unwraps packages and adds their contents to your Solaris systems is pkgadd. Although it can be invoked with a variety of options (use man pkgadd for additional detail), the most common way is pkgadd -d . The parameter is the directory location where the package is found -- on a mounted CD-ROM, for example -- and is the name of the package you want to install in the target system. To aid software management, package names have a four-character prefix reserved for the vendor's ID. Sun-developed packages start with "SUNW," and the package "SUNWwabi" contains Sun's Windows emulation application and related package files.

Besides adding complete applications to your systems, another handy use of packages is to amend or restore removed parts of the system's OS and applications. For instance, you might mount the Solaris CD-ROM and add the sound support package to your SPARCstation: pkgadd -d /cdrom/Solaris_2_3/s0/Solaris_2.3 SUNWaudio. Almost all of Sun's software patches are now shipped as installable packages, too. This is handy because the patch installation scripts included in the package make sure that your system is capable of accepting the patch before making any modifications.

Package removal is just as easy as installation, using the pkgrm command. It automatically and completely removes any and all traces of the specified package from your system. If other packages are dependent upon the selected package of software, you'll be warned that you are heading for disaster and asked to verify its removal. You might want to jot down the removed package names so you'll be able to put them back later, if desired.

Tracking 'em down
You probably are wondering by now how the package system knows which files to remove. Magic, of course -- and a database file that gets updated every time you add or remove packages from your system. The pkginfo command queries this database and, in its simplest form, lists the names with a one-line description of every package currently installed on your Solaris system. Using the common -l option and appending a package name to the command gives you detailed information about that package, including the vendor name, package description, version number, and so on. Combining pkginfo with grep lets you do an extensive search for all related files on your system. For instance, pkginfo | grep Windows* will list all packages containing parts of the window system.

The magic package database file? It's /var/sadm/install/contents. Damaging or removing it inevitably results in shortness of breath and heart palpitations for your Solaris system administrator, so be extra careful with that file, particularly if that administrator is you. There is no way to reconstruct the file short of completely reinstalling your system and software. Although it can become quite large, consuming a few megabytes of space in your already cramped root filesystem, resist the urge to remove or modify that contents file unless you are sure you have a reliable backup.

Point-and-click packaging
While pkgadd, pkgrm, and pkginfo get the job done in typical Unix fashion, like other shell scripts they can be tedious to use. In their stead, use the graphical, integrated application swmtool. When started, swmtool displays a list of all the packages on your system. You can select one or more packages with the mouse, and individual radio buttons let you obtain more information about the packages as well as "Remove" them from your system.

Package installation with swmtool is also simple: Set the "Source" property to a mounted filesystem and directory, such as on a CD-ROM, and swmtool automatically displays a list of all packages found within that source. Select the packages you want, and click Install. For added convenience, swmtool tells you the current size and how much space the package will consume in your various filesystems before you elect to do the installation.

Occasionally, related packages are grouped in a "cluster." For example, the Sun C++ compiler is installed as a cluster of packaged applications, including the compiler front end, code generators, and optimizers. By selecting Install, in one step you install all its constituent packages into your system. Or, if you want to install only part of a cluster, swmtool lets you do that, too.

Wrapping your own
With special construction tools, developers can take advantage of packages for the distribution, installation, and management of their software. Creating a package is straightforward and, for the most part, automated.

First, you build a prototype file with the pkgproto tool. Specify where the target files are located, and the utility automatically collects and stores in the prototype file detailed information about your software that will be used by subsequent utilities to create a package, such as file ownership and permissions, time stamp, and so on. (see the man prototype pages for a detailed description of the prototype file contents). Although creation of the prototype file is mostly automated by pkgproto, you will have to manually edit portions of it using vi or a similar sourcefile processor.

At minimum, you need to add to the protoype file the search path that tells the package builder where to find your files and the location of the special pkginfo file. The manual pages on pkginfo give you a sample file that you can manually modify using vi or a similar sourcefile processor. Among other things, the pkginfo file contains the name of your package, its version number, vendor contact information, and other package dependencies used by the software packaging system to manage the package.

Finally, with valid pkginfo and prototype files in hand, you're ready to build your software package with pkgmk. Optional command parameters let you set the target device or directory for your package and specify the prototype filename if it isn't "protoype." The pkgmk utility creates a complete package directory, ready for installation on your own or other Solaris system. Simply tar it and other packages onto a tape, removable disk, or optical disc.

Managing packages
Clearly, managing Solaris 2.x systems is considerably less onerous if you use packages. When confronted with an unfamiliar system, a quick scan of the output of pkginfo gives you a great overview. You also see what's been patched -- an important clue in tracking down some bugs.

On more than one occasion I've received complaints that a system is unable to compile even trivial programs. Rummaging through the package listings, I find that the SUNWhea package, which contains the C system include files is missing, usually because whoever installed Solaris elected not to include the "Developer's Option." The quick fix, of course, is to pop in the Solaris CD-ROM and run swmtool or pkgadd to retrieve the appropriate cluster files. Similarly, because package removal is so easy, I've been able to forestall expensive disk upgrades by cleanly and easily removing little-used files or by stripping a system down to its bare, but essential, bones with the package utilities.

All told, the Solaris package administration tools are an effective, standardized way to manage software installation and removal. While not widely publicized as a compelling feature of Solaris 2.x, they should nonetheless be a part of every system administrator's toolbox. And I strongly encourage software developers to distribute their applications as packages, cleanly integrating their products into the orderly world of Solaris software packaging. Let's stop abusing our systems and users with outdated, frustrating software installation and removal practices.

About the author
Chuck Musciano is an experienced software engineer with the Corporate Information Management Group at Harris Corp. He can be reached at chuck. musciano@advanced.com.

If you have problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/asm-02-1995/asm-02-sw.tools.html.
Last updated: 1 February 1995.