One of the criticisms frequently launched at the *nix platforms is the procedure used to install new software. Although I don't think that the command string "./configure;make;make install" is beyond the capabilities of the average 12-year-old, many decry it as being too archaic, pointing to the installation wizard available on Windows as the way it should be done. This month, I'll investigate various "wizards" available to Linux users that duplicate, indeed exceed, the functionality of the Windows counterpart.

Back to the Source

Before we delve into our other options, let's start with basic *nix software installation. Once you've read this section, you'll understand why the *nix pundits criticize the process.

Although open-source software is almost always available as a precompiled binary, you'll occasionally find a program that is available in source form only. Should you uncover one of these, or if you wish to use the bleeding-edge version of a program, you'll need to roll your own binary. Typically, you obtain the source code from either an FTP server or the project's Concurrent Versions System (CVS) server (CVS was discussed in this column in November 2002). Once the source files are downloaded and installed on your system (the procedures for which vary and are normally described on the project Web site), the commands I mentioned earlier ("./configure;make;make install") are what would typically be used to install that program. The command "./configure" runs a script that verifies the existence and location of any compilers or libraries that will be needed to compile the program.

Assuming that you have all of the requirements (compilers, libraries, tools) loaded on your system, "make" is the GNU tool that, when called without parameters, performs the magic of compiling and linking the program into binary form. If no errors occur during the compilation process, "make install" will transfer the binaries and associated man (manual) pages to their final place on your *nix system.

So what's the problem with this scenario? Nothing, really--except that, as the system administrator, you'll have quite a bit of manual bookkeeping to perform. You'll need to keep an inventory of the software you install so that you can keep your system up-to-date when enhancements become available. The inventory will be useful when you want to create similar systems with identical software suites. The inventory will be invaluable when you wish to clean up a system, removing unused packages and reclaiming space.

Thus, you can build and maintain a system using virtually nothing but source code. Obviously, the fact that something can be done isn't usually reason enough to actually do it. There has to be a better way--and there is.

The Better Way

Most modern Linux distributions (and commercial unices) have some automated means of managing installed software. For the Red Hat, Mandrake, and SuSE distributions, it is called the Red Hat Package Manager (RPM), which is the main thrust of this article.

Software that has been bundled into an RPM "package" can easily be installed or removed with RPM in a manner similar to the Windows Add/Remove utility. But RPM has functionality beyond the Windows counterpart. RPM can also...

• Tell you the packages that you have installed on your system, as well as their versions.
• Provide the list of files that comprise a package.
• Given a specific file's name, tell you which package "owns" it.
• Prevent you from deleting a package upon which one or more other packages depend and tell you the names of the dependent package(s).
• Prevent you from installing a package for which dependent packages are required but are not currently installed.
• Update an existing package to a newer version or "downgrade" a package to a previous version.
• List any files that have changed since they were installed, whether it be a change in permissions, ownership, or content.
• Validate the package's source so you can be sure that the contents contain what the originator intended and that no nefarious schemes are being perpetrated.
• Show you the scripts that will be run during the installation of a package, allowing you to determine what the package will be doing both pre- and post-installation.

As you can see, RPM is an extremely powerful package that has many advantages over its Windows cousin, not the least of which is the fact that it is open source. This means that you can use it yourself to package your own software without having to purchase an installation builder (which you must do if you want to use the Windows installer).

Most open-source software is available in binary form already bundled into an RPM file, so typically you only need to download the appropriate package and then issue the command rpm -ivh the_complete_package_name.rpm to have the software installed on your system. We'll look at an example shortly.

What if your desired software isn't available as an RPM, but is, instead, only available in source form? You might consult the manual for RPM and learn how to code RPM specifications. An easier solution is to use a program called checkinstall, which is used in lieu of the "make install" step mentioned earlier. This program creates an RPM package "on the fly," based on the actions performed by make. The result is that the software will be compiled, bundled into an RPM file, and installed on your system.

Now, let's turn our attention to a real-life example of using RPM to install software. I'll be using the command line to accomplish this, but for you visual types, there are GUIs to accomplish the same tasks. These include kpackage (for KDE desktop environment users), gnorpm (for Red Hat 7.3 and earlier), and redhat-config-packages (for Red Hat 8 and newer).

The software we'll be installing (and removing) during this demonstration is the Linux driver for IBM's 2085 printer/copier. Let's start by looking over the package to see what might be interesting (the output has been reformatted to fit the available space):

I have truncated the file listing, but, as you can see, there is a ton of information stored within the RPM file. It is curious to note here that IBM deviated from the standard naming convention for RPM files. The supplied RPM file is called "PrintTool_enu.i386.rpm," yet the package is called "IBMPrintTool." What's worse, the original source RPM had a name that followed convention, so, obviously, someone renamed the thing prior to burning the driver CD from which this file was obtained. Thank you very much for the confusion.

Want to see what scripts will be run when RPM starts installing this package?

There are two scripts here. The first, called the "postinstall" script, is called once the software has been extracted to the appropriate directories. In this case, all the script does is display an IBM splash screen. The second, called "preuninstall," is called prior to the removal of the software (if that is ever done).

Now that our curiosity is satisfied, let's install the software. The command to do that is short and sweet:

We can easily check to verify that the package is a part of our system:

Finally, let's remove the package from our system and then verify that it is gone:

That's the quick tour of RPM. I know what you're thinking: Where are the warts? There is one big one that I find annoying. As I mentioned earlier, RPM will preclude the installation of software for which at least one of its dependencies is not loaded. It will tell you the name of the missing file(s) but will not tell you which software package provides the file(s). It's not that the information isn't available--at least one web site offers a reverse "which package has this file?" inquiry. But once you know the names of the missing packages, you still need to download them manually and then install them either in order of dependency (one by one) or by typing them on the command line together: rpm -i package1 package2 ... package n.

And the torture never stops. If any of the packages that you try to install have missing parts, you'll need to repeat the game of hide-and-seek you've just played, locating the missing packages until you have all dependencies satisfied.

I can't speak about SuSE or Mandrake, but Red Hat does have another facility that takes care of all of this for you. It's called up2date, and it uses the Red Hat Network Server and the Internet to allow you to keep your system up-to-date (and to install new software). For example, if I want to install a particular package, say PackageA, all I need to do is type up2date -i PackageA, and it will do all of that work for me. The Red Hat Network is a subscription service that has a per-machine fee. Red Hat will give you one machine free (with access on a "resources-as-available" basis); you can get additional entitlements as needed. For those who have wondered how anyone can make money giving away software, this is one example of how to do it. I have a number of entitlements and am more than happy to throw some money Red Hat's way just for this service.

Now, That's YUMmy!

What if you don't want to spend the money for an entitlement for each of your machines? You have another option: more open-source software. I have a location that has for its Internet access a pathetically slow dial-up modem connection. So, even though the pocketbook is willing, the body can't make use of the up2date function. In this case, I have created a local version of an up2date server using a package called the Yellow dog Updater, Modified, or Yum. By copying all of the RPM files from the distribution CDs and then adding the update RPM files available from Red Hat (which I bring in on my laptop from home), I can create a Yum server with ease using only a standard FTP or HTTP server (conveniently available in all Linux distributions). Yum uses RPM "under the covers," but it does all of the nasty dependency checking for you. I encourage you to visit the Yum Web site for a complete overview of this wonderful product.

Something More Apt?

Aficionados of the Debian Linux distribution are out of luck when it comes to RPM. They do have their own equivalent, though. It's called "apt," and it has many of the same facilities as RPM (some say more). Commands such as apt-install or apt-update help keep the software inventory on your Debian system under control. Should you, too, become enamored of apt (RPM versus apt is another one of those geek holy wars), you can get a port (called apt-rpm) to manage your RPM-based system. I do not currently have any Debian-based systems to manage, so I admit to only a passing familiarity with it.

You aren't giving up the ability to manage your source-based software by using Debian. The checkinstall utility I mentioned earlier is capable of generating DEBs (the apt package file), so you'll have the same convenience in either RPM- or DEB-based systems.

Making It Easier

I'm always looking for ways to minimize the amount of time I need to manage a system. My motivation for this article came from an individual who was having issues with writing a script to start and stop a daemon. Upon investigation, I found that he had downloaded and installed the tar ball version of the product in question instead of the RPM version, which was available from the same place. The result was an installation that required a lot of manual tweaking to get it running properly. Once that oversight was corrected and he had installed the RPM for the software, he had an installation that meshed perfectly with his Red Hat Linux system.

Take some time to get familiar with RPM (or apt). The power of these tools will make your administrative job much easier, allowing you get on to more interesting things than software inventory management.
That's it for this month. If you have some vexing problem that you'd like me to address in future columns, please drop me a line.

Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 20 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He recently co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..