2.1. Introduction

Installing a Linux distribution is quite easy these days. Pop in a CD-ROM, make a few configuration choices, then go enjoy a cup of tea while it finishes. Modern Linuxes have excellent hardware detection, install quickly (typically in 30 minutes or less), and require no more than a single reboot.

2.1.1 Source-Built Systems: The Olde Way

Maintaining a Linux system has also evolved tremendously. Packages and intelligent dependency resolvers mean that keeping a system updated and patched is now easier and less error-prone. Today's youngsters have it so easy. We didn't have CD-ROMs in the primitive olden days of computing—instead of broadband, we had a station wagon full of floppy disks. To get new programs, us old-timers had to unpack laboriously downloaded tarballs, or copy them off floppy disks, then compile the programs from source code. Dependency problems? Why, us old geeks handled all those things without help from any fancy-pants dependency resolvers. It went something like this:

# tar -xvf someprogram.tar

# ./configure

# make

The make failed, because of unresolved dependencies. So the next step was to download a tarball containing the program with the required libraries, which took six hours over a 300-baud modem. You know, the kind with the rubber cup that fits over the phone. I passed the time by going outside and planting a garden. I came back inside when the download was finished, unpacked the new tarball, and tried again:

# ./configure

# make

Boy howdy, another long string of error messages indicating more unresolved dependencies. Download yet another tarball, do more garden work. By the time everything was installed and working, I had tomatoes the size of melons. It's a good thing we were so smart we hardly even needed computers.

Why was there all this dependency drama? Because Linux uses shared libraries that are dynamically linked at runtime. Many separate, unrelated programs can use the same libraries. This makes for a fast, efficient system. Less memory and storage resources are consumed, and programs are smaller and easier to distribute. But as Linux evolved and became more complex, managing source-built systems became more difficult. So programs were put into packages. Packages include compiled binaries, pre- and post-installation scripts, file indexes, uninstallation scripts, and other goodies. Each package knows what it needs to resolve its own dependencies. Package databases track all the installed-from-package files on a system.

2.1.2 Dependency Resolvers

However, not all was bliss in Whoville. RPM, the Red Hat Package Manager, is the most widely used Linux package manager. RPM is quite powerful. It runs dependency and version checks, and it tracks all installed packages in the RPM database. But it cannot fetch additional packages to resolve dependencies, nor can it manage the relationships between packages. When it gets stuck because of dependency problems, it tells you what additional packages to install, which means you have to find these packages and install them. This can lead to more dependency conflicts, and a simple installation can go haywire in a hurry. This is known as "RPM hell."

Many dependency resolvers have been developed for RPM-based systems, including apt-rpm, urpmi, Yum, and Ximian's Red Carpet. There are excellent distribution-specific installers/resolvers, such as Red Hat's up2date and SuSE's YaST and Maintenance Web. In this chapter we'll cover RPM basics and Yum, which was developed natively for RPM systems. For many users, Yum strikes the right balance of features and ease of use.