If Microsoft Windows 9x has one good feature, it's the installer -- the program that helps you install and remove programs. The installer is a significant improvement over earlier program installation facilities. In the days of MS-DOS and Windows 3.x, software installation was something of a hit or miss proposition. For exam-ple, if you installed a program to a specific folder, rather than accepting the default folder, you often found that the program failed to work.
If Microsoft Windows 9x has one good feature, it’s the installer — the program that helps you install and remove programs. The installer is a significant improvement over earlier program installation facilities. In the days of MS-DOS and Windows 3.x, software installation was something of a hit or miss proposition. For exam-ple, if you installed a program to a specific folder, rather than accepting the default folder, you often found that the program failed to work.
Software installation under Linux is not quite yet as convenient as that under Windows 9x. Still, as Linux has grown up over the last several years, the situation has gotten better. Today, all of the Linux distributions use package managers for software installation. Before the advent of package managers, unless you really knew what you were doing, installing software under Linux was definitely not a day at the beach. Now, maybe it’s more like a rainy day at the beach.
Because there are so many different ways to install software, there is much more material than can be covered in one article. So welcome to the first article in our three-part series on software installation. It probably makes sense to cover the most popular Linux package managers first (the Red Hat Package Manager (RPM) and the Debian package manager), so that’s where we’re going to start. Over the next two months, we’ll discuss how to install software that has not been nicely pre-packaged for easy installation.
What Good is a Package?
Simply, packaged programs make life easier for users by “packaging” all of the various parts of a program together into a single file. This allows users to conveniently install the program without fretting about which parts they are going to need, or where they are going to go. If you had to install each part individually, you’d find the procedure both tedious and error-prone. Consequently, your Linux system probably would not contain very many programs — or at least, not many working ones.
Packages present another important benefit: They help you sort out dependencies and conflicts. What’s a dependency? Well, quite simply, some packages can’t function without the capabilities provided by one or more partner packages. Packages such as these are called dependent packages. Dependent packages contain information identifying the capabilities they need, so that the package manager can decline to install the package unless these capabilities are available. This helps ensure that any installed programs will work properly.
Package conflicts are the result of packages that don’t get along and should, therefore, be kept separate. Suppose you try to install a package whose files conflict with installed files. The package manager can recognize this situation and decline to install the package; otherwise, installing the package might break existing programs.
So yeah, this is all well and good, but how do these package managers work? Quite well actually…
A typical package manager, such as RPM, can do a lot more than install packages. The package database gives the package manager knowledge of each installed package and its component files. Using this information, the package manager can support functions such as:
* Uninstalling a package and all of the files it comprises.
* Querying the package database to list installed packages and their characteristics, such as when they were installed.
* Querying a package file to determine its contents.
* Verifying a package by comparing its meta-information to files that have been installed. For example, you could use this function to identify configuration files that have been altered since package installation.
The Name Game
|Figure One: Naming conventions for Debian and RPM packages.|
Package managers generally prescribe a naming convention for package files. Figure One shows the conventions used by RPM and the Debian package manager. Each package file name has several fields:
* The package name
* The package version number
* The package release number
In addition, RPM package file names include a field that identifies the computer architecture for which the package is intended:
*i386 indicates a package for use on an IBM-compatible PC
*i586 indicates a package for use on Pentium-class IBM-compatible PC
*noarch indicates a package for use on any architecture
The package release number is used to serially number releases. When two package files have the same version number, you can use the release number to tell which package file contains the later release. For example, consider the RPM packages circus-2.0-4.i386. rpm and circus-2.0-5.i386.rpm. The package file circus-2.0-5.i386.rpm contains the newer release, because its release number (5) is greater than the release number of the package file circus- 2.0-4.i386.rpm (4).
These package file naming conventions are helpful. But, the power of package management doesn’t lie in the names of package files. RPM, for instance, doesn’t care about the name of a package file. Names are merely for human use.
Instead, package managers rely on information stored in package files. A typical file contains not only the program itself, but also a number of configuration, data, docu-mentation files and meta-information. The term meta-information means information about information. The meta-information in a package file describes such package characteristics as:
By this time you might recognize a few of these terms — but the Checksum is new one. A checksum lets the package manager verify whether the package file is intact. The dependency and conflict information lets the package manager determine whether it should comply with an instruction to install the package.
How to Install an RPM Package
Now that you know something about how package managers work, let’s take one out for a spin. I’ll explain the process for installing an RPM package, which applies if you’re using Caldera, Mandrake, Red Hat, SuSE, TurboLinux, or another RPM-based Linux distribution. If you’re using Debian GNU/Linux or a Debian-based distribution such as Corel Linux or Storm Linux, the same concepts apply but the steps are somewhat different.
The most convenient way to install an RPM package is by using the X-based utility gnorpm. To use gnorpm, you must log in as root; ordinary users are not allowed to install RPM packages. You may find the gnorpm utility on the menu or launcher of your desktop. If not, you can start it by launching a terminal window and issuing the following command:
|Figure Two: Installing an RPM package through gnorpm.|
When gnorpm starts, you’ll see a window that resembles the window in the background of Figure Two (pg. 30).If you click on the Help menu, gnorpm will display a pull-down menu of help documents you can view.
To install an RPM package, click the Install icon. A window that resembles the window in the foreground of Figure Two should appear. If your distribution CD-ROM is mounted at the proper mount point (generally /mnt/cdrom), the left pane of the window will show the package files the CD-ROM contains.
If you don’t see the package files, check that the CD-ROM containing package files is properly mounted. If it is, click Close to dismiss the Install window and click Operations->Preferences. Use the dialog box that appears to specify the correct location of your package files.
Click the check box next to the package files you wish to install and click Install. The gnorpm utility will install the selected packages.
|Figure Three: You can use the Web Find feature of the gnorpm utility to scan all of your favorite Web sites for current RPM packages.|
One of the handiest features of gnorpm is Web Find, which lets you search popular Web sites for RPM packages. To use Web Find, establish a connection to your Internet Service Provider then click Web Find. A window that resembles that shown in Figure Three (pg. 33) should appear. If this is the first time you’ve used Web Find, gnorpm will spend some time gathering information from Web sites. If your Internet connection is slow, this process may take several minutes.
Eventually, the left pane of the window will show an enormous list of available packages. You can search the package list by using the text box and button at the top of the window, or you can browse the tree by clicking nodes to expand them.
To install a package, highlight its name in the left pane and click the Install button. If you prefer to download the package for later installation, you can click the Download button, which will save the package file to disk without installing it.
The Web Find feature is one of those things that sounds like a really good idea, but in reality is not quite as reliable as one might wish. In fact, it is frequently the case that a site listed as hosting a given package will not be available or no longer offer that package. But when it does work, Web Find‘s a pretty sweet feature.
Given the chaos and frustration they help us avoid, package managers are among the most useful programs to come around in the past several years. However, despite all of the benefits they bring, there are still quite a few limitations that I’m sure users would like to see package systems overcome:
* Files are generally platform dependent. If you want to install a package, you must find the right package file for your platform.
* Programs distributed by means of package files have pre-specified options. If the package that you are installing wasn’t built using an option you want — even if the program supports that option — then you may be unable to use that particular option.
* Programs distributed by means of package files don’t generally include source code. If you’re truly an open source fan, wouldn’t you prefer to work with the source?
Speaking of that last point, over the next two months we’ll be looking at source code packages and distributions, which represent two ways of overcoming the limitations of ordinary packages we’ve mentioned here.
Until then, good luck!
|Figure One: Package manager components.|
To better understand how a package manager works, see Figure One,
which shows the components of a typical package manager, such as RPM. The package manager interacts with four components:
The User Interface:A user directs the operation of the package manager. The RPM package manager includes a command-line user interface, the rpm command, and a graphical user interface, gnorpm.
Package Files:A package file contains the program, configuration, and data files that are to be installed on the system. The package file also contains meta-data that describes the package it comprises.
The Package Database:The package database describes every installed package. For example, using the database, it’s possible to determine to which package a given file belongs.
The Installed Package Contents:The installed package contents consist of the installed program, configuration, and data files.
Bill McCarty is an associate professor of information technology at Azusa Pacific University, Azusa, CA. He can be reached at firstname.lastname@example.org.