Issue #1 November 2004

Better Living Through RPM, Part 1

by Chip Turner

Introduction

The growth of Linux from hobbyist plaything to professional computational platform brought with it a number of changes, some evolutionary and some revolutionary, that were clear improvements over the Old World of UNIX. Among these improvements is the evolutionary growth of software packaging, from its early days simply as tarballs to its much more advanced and modern embodiment, RPM. Ask anyone what RPM is and they will answer something about packaging and, very likely, also mention Red Hat. And although it is true that RPM was originally created by Red Hat for its Red Hat Linux operating system, it has been adopted by a number of other Linux distributions because of its powerful capabilities and has become largely ubiquitous among commercial Linux distributions.

RPM (which is a recursive acronym standing for RPM Package Manager) can be divided into three main areas of functionality — the packages (files that are compressed and contain applications, data, and other files, not unlike a tarball or zip file), the database (a list of the installed packages on a given system), and the compilation recipe (which is what turns piles of files into actual packages suitable for installation on other systems). This article focuses on the first two, manipulating packages and the database on your system.

Note:
As a note of terminology, this article uses RPM when referring to RPM as a whole and rpm when referring to the command line utility with which the majority of interaction with RPM takes place.

Although there are a number of differences between a simple tarball and an actual RPM, one of the most important differences is the concept of versioning. Every RPM has a version (indicating the version of the software it packages, typically the same as the open source project on which the RPM is based), a release (best thought of as the version of the RPM packaging of a particular version of software), and an epoch ("magic" that generally is hidden and does not visibly affect usage). Another extremely significant difference between RPMs and simple tarballs are dependencies. A dependency is basically a statement a package makes that says "I require other software to run properly," where the other software could be a file, a shared library, or even the name of another package. In its default mode of operation, RPM does not allow a package to be installed unless all of its dependencies are met.

On a typical Fedora Core 1 install, there are between 700 and 1200 packages present. Each of these packages contains hundreds or even thousands of files on your the system. In fact, almost without exception, every single file on your file system came from an RPM (aside from those you place manually yourself, of course).

To begin our exploration of RPM, we start with the RPM database of software you have installed. The most basic query is to determine if a package is installed. Suppose you want to see if, say, a game called xgalaga is installed. Type the rpm -q xgalaga command and rpm either reports the version of the package installed or, more likely, reports that it is not present. Further, with a simple command line, you can search the database to discover what package the file /bin/sh is from. To do this, at a shell prompt, type the rpm -q -f /bin/sh command. rpm responds with the name, version, and release of the package /bin/sh came from. In the case of Fedora Core (and every Linux distribution known to man), this is part of the bash package.

But what exactly is bash? Fortunately, the RPM database can tell you more about bash too. Type rpm -q -i bash to see just what bash is. Example 1, “Output of rpm -q -i bash” shows the output. Among the data presented is a human-readable description in paragraph form informing us that bash is the Bourne Again Shell. 

Name        : bash                         Relocations: /usr
Version     : 2.05b                             Vendor: Red Hat, Inc.
Release     : 34                            Build Date: Tue 09 Dec 2003 01:07:19 PM EST
Install Date: Tue 23 Mar 2004 10:24:45 PM EST      Build Host: thor.perf.redhat.com
Group       : System Environment/Shells     Source RPM: bash-2.05b-34.src.rpm
Size        : 4519964                          License: GPL
Signature   : DSA/SHA1, Tue 23 Dec 2003 10:30:11 AM EST, Key ID b44269d04f2a6fd2
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla/>
Summary     : The GNU Bourne Again shell (bash).
Description :
The GNU project Bourne Again shell (bash) is a shell or command
language interpreter that is compatible with the Bourne shell
(sh). Bash incorporates useful features from the Korn shell (ksh) and
the C shell (csh) and most sh scripts can be run by bash without
modification. Bash is the default shell for Red Hat Linux.
Example 1. Output of rpm -q -i bash

These simple examples show us two key things. First is that (almost) all interaction with RPM is performed through the command line utility rpm. Second is that RPM maintains quite a bit of information about any package that has been installed. We now turn our attention to exploring the information that RPM tracks (both in the packages themselves as well as the database of packages you have installed).

Querying

The general term applied when using the rpm utility to discover information is querying. Although you use a single command to access the variety of functionality inside of rpm, it is best to think of rpm as having modes. Typically the first parameter on the command line after rpm itself is the choice of modes. In the previous examples, this was -q which, not coincidentally, indicates the query mode of rpm should be activated. The subsequent parameters, -i and -f, are submodes of the query mode, representing information about the installed package and what package a file is in, respectively.

Typically, one sees the mode and submode parameters concatenated together on the command line. So, in this case, we could just as easily have used rpm -qf /bin/sh or rpm -qi bash in the previous examples. This form of invocation is used for future examples as it is so common as to be idiomatic in the RPM world.

In addition to -i and -f, rpm can also list the files in an installed package. To see what is contained in the package named setup, type rpm -ql setup. This produces a list of the files contained in the package. To retreive more information on those files, in a format similar to ls -l, add a -v (for verbosity) submode. In this case, the command is rpm -ql -v setup, though you can actually toss the -v into the -ql and abbreviate it as -qlv.

Although a typical system has hundreds of packages installed, sometimes it is useful to query the RPM database and retrieve a full list of installed packages. This is the -a submode of the query mode: rpm -qa. Typically one would use grep to filter this output, as it tends to be quite a bit of data; for instance, rpm -qa | grep ^perl lists all packages whose name begins with perl. Another use of this command is to take a snapshot of the installed packages on a system, saving it for later comparison (or for comparison against another machine, for example). An example of this more complex usage is seen in Example 2, “Comparing Different Stages of the RPM Database”, where manifests are saved and show how to use the diff utility to detect package removals or additions. In fact, there is a cron job on most systems that records changes in the installed package list and saves the output to /var/log/rpmpkgs (with older versions of the file being rpmpkgs.1, rpmpkgs.2, etc). Consult /etc/cron.daily/rpm for details on how this file is created. 

# rpm -qa | sort > /tmp/before.lst
# rpm -e wget
# rpm -qa | sort > /tmp/after.lst
# diff -u /tmp/before.lst /tmp/after.lst
--- /tmp/before.lst     2004-03-24 09:55:58.000000000 -0500
+++ /tmp/after.lst      2004-03-24 09:56:10.000000000 -0500
@@ -712,7 +712,6 @@
 vte-0.11.10-4
 w3c-libwww-5.4.0-7
 webalizer-2.01_10-14
-wget-1.8.2-15.3
 which-2.16-1
 wireless-tools-26-1
 words-2-21
Example 2. Comparing Different Stages of the RPM Database

The dependencies mentioned earlier can also be explored via querying. Generally speaking, a dependency takes the form of depname or depname comparison version. Simply put, depname is any string, be it a filename, package name, or internally generated dependency. Dependencies, like packages, can contain versions, and sometimes it is necessary for this version requirement to be stated explicitly (hence the comparison version portion of the dependency). For instance, you might find a perl module that has a dependency like perl >= 5.8.0, indicating perl version 5.8.0 or higher is required for the package to be installed.

Much like other querying modes, one must provide a command line option to see the inner workings of dependencies. This time, though, the parameters are a bit more verbose: 


rpm -q --requires kernel
rpm -q --provides kernel

These commands show the dependencies the kernel package has on other packages as well as the list of the dependencies that having the kernel package satisfies.

It is possible to turn around these queries, though, so that instead of asking “what does package X provide or require?” you can ask “what packages require Y?” For instance, rpm -q --whatrequires glibc lists all installed packages that require glibc. However, the output here is a bit suspicious — can it be possible so few packages require glibc? Actually, almost every package requires glibc, but the command line of RPM is very specific with --whatrequires and --whatprovides; instead of answering the perhaps intuitive question “what do I have installed that requires glibc or any of the libraries inside of glibc?”, --whatrequires answers “what packages explicitly mention requiring glibc?” This seems less helpful, but with a little work, one can get a better idea of what requires glibc by asking the RPM database “what requires the package named glibc?”, “what requires anything the glibc package provides?”, and “what requires any file inside the glibc package?”. Even so, this is a bit complicated; fortunately it isn't usually necessary. Refer to Example 3, “Determining What Really Requires glibc” for the exact commands. 


rpm -q --whatrequires glibc > /tmp/glibc-dependencies.txt
rpm -q --provides glibc | xargs rpm -q --whatrequires >> /tmp/glibc-dependencies.txt
rpm -ql glibc | xargs rpm -q --whatrequires >> /tmp/glibc-dependencies.txt
sort -u /tmp/glibc-dependencies.txt | less
Example 3. Determining What Really Requires glibc

As a side benefit of learning how to ask the RPM database about packages you have installed, you also now know how to ask similar questions to individual packages that you have not yet installed. To query against a package on the file system, use the -p submode of -q. For example, supposing you have a file named bash-2.05b-31.i386.rpm, you can see the same info you would get from rpm -qi against the package itself (without having to install it first) with this invocation: rpm -qi -p bash-2.05b-31.i386.rpm. Likewise, you can get the list of files in the package with rpm -ql -p bash-2.05b-31.i386.rpm. Most of the previously mentioned query modes also function against individual packages. This is particularly useful when determining whether or not you want to install a package.

Since RPM knows so much about every package a system has installed, it stands to reason that it can perform some sanity checks (for instance, to see if a file was deleted that should be there). This is performed from another mode of RPM called verify (invoked via -V). Though similar to the query modes, do not be fooled; verification is more than a way to satisfy curiosity about a system and can be used to ensure that the installed system has not been damaged and that the installed packages have what is known as dependency closure (which is just a technical way of saying there are no missing dependencies).

"Since RPM knows so much about every package a system has installed, it stands to reason that it can perform some sanity checks."

For example, suppose you have reason to believe that the file /etc/bashrc has been modified. To determine whether this is or is not the case, you could compare the file to a freshly installed, known-good system running the same version of the bash, but RPM already knows the answer to the question. The first step is to find out what package this file came with. This can be determined with rpm -qf /etc/bashrc which shows us that the setup package owns this file. Now we invoke RPM's verify mode via rpm -V setup. This may produce some peculiar output, depending on your system. For example, the output in my case is as follows: 

S.5....T c /etc/printcap
..?..... c /etc/securetty

The first column of output is the state of the file, which is what we are interested in here. In this case, we are told that the file has a different size, MD5 checksum, and time stamp than RPM thinks it should (a telltale sign someone edited my /etc/printcap!). Table 1, “Legend for rpm -V” contains a legend that shows what these fields mean, as does the rpm man page.

Position Symbol Meaning
1 S File size differs
2 M Mode or permissions differ
3 5 Checksum differs
4 D Device major or minor number differs
5 L Symlink changed
6 U User ownership changed
7 G Group ownership changed
8 T Last modified time changed
Table 1. Legend for rpm -V

A similar operation is to ask if any files at all, in any package, have been modified, deleted, or otherwise mangled. This is best seen by the rpm -Va command. Be forewarned, this can take a significant amount of time to complete (after all, it is checksumming every file that RPM manages, which is nearly every file on the file system). It is, however, extremely thorough and can give you a very good idea what has changed on a system since it was installed. An important note here is that this mode of verify should not be considered a replacement for software such as Tripwire and Samhain that also can watch for modified systems; though RPM does track that data, more formal software suited for this task uses more advanced cryptography to ensure the validity of not only the files but the list of checksums of those files. A quicker version of this command can tell you if you have any unsatisfied dependencies: rpm -Va --nofiles performs a verify on all packages without actually checking details about each file.

Installing and Removing Packages

All of the queries in the world quickly become useless if you can not actually change the data you are querying, and in the case of RPM, that means installing and removing packages. Traditionally, installation and removal have been performed on the command line, and this article focuses on that, but there is also a relatively new GUI for performing installations that greatly simplifies some parts of it.

As with querying and verification, we introduce a new mode to the rpm command. Actually, we introduce several, though they are closely related. The first is the most basic — a package install. This command line mode is -i, which represents install as one might expect (remember, there is no -q in this command; rpm -q -i is very different from rpm -i since, in the former case, the major mode is -q, whereas in the latter case, the major mode is -i). The usage here is very simple: rpm -i filename.rpm. This installs a package (or more than one; it accepts a list of files), resulting in no output if the package was successfully installed. Frequently, though, it is nice to see output since, especially with multiple and/or large packages, it can take a while to complete the operation. So, we add a -v submode like before with -qlv and now rpm tells us each package name as it is installed. This is an improvement, but rpm can go a bit further with the -h submode, which results in a progress bar as the package is installed. These three go hand in hand so often that you generally see them grouped idiomatically: rpm -ivh filename.rpm.

Installation is good, but in the world of RPM, it means a very specific thing — take a package, see if it has any conflicts, and install it if it does not. Missing is a step many users may take for granted — if an older version of the package is installed, remove it while you add this one, which in effect upgrades the package in question. If you try to use -i on a newer version of a package you have installed, you will likely see an error message. For example, the rpm -i /tmp/wget-1.8.2-15.3.x86_64.rpm command might produce output similar to Example 4, “Example Installation Error Message”. 

file /usr/bin/wget from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/info/wget.info-1.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/info/wget.info-2.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/info/wget.info-3.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/info/wget.info-4.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/info/wget.info.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/man/man1/wget.1.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
Example 4. Example Installation Error Message

This error is saying that there are conflicts between the new and old version of the package (that is, the same file is in both packages). Why would RPM behave like this; why does it not just assume you want to upgrade? Basically it revolves around the fact you can have multiple packages of the same name installed. This is best seen with the kernel package (go ahead, rpm -q kernel to see how many you have). Generally this is not a commonly used feature, but it is here nonetheless.

RPM does give you an upgrade mode, though, that behaves very much like a user would expect — “if this package is not installed, install it; if an older version of this package is installed, upgrade it.” This is the -U mode, and it behaves very similar to -i (even so far as to be idiomatic: -Uvh), but it is more along the lines of “do what I mean.” The vast majority of the time, -Uvh will be the command you reach for when trying to install or upgrade packages.

There is a third installation mode, called freshening, represented by -F. This is similar to -U in that it upgrades a package that is installed, but it adds one restriction — ignores any packages that are not of the same name as a package that is already installed as shown in Example 5, “Example of Using the Freshen Mode”. 

# rpm -q wget gaim
wget-1.8.2-15
package gaim is not installed
# rpm -Fvh wget-1.8.2-15.3.x86_64.rpm gaim-0.75-1.3.0.x86_64.rpm
Preparing...                ########################################### [100%]
   1:wget                   ########################################### [100%]
# rpm -q wget gaim
wget-1.8.2-15.3
package gaim is not installed
Example 5. Example of Using the Freshen Mode

Basically freshening is useful when you have a directory full of files (say, security updates) that you would like to apply, but you do not want to suddenly have a large number of new packages installed. You can execute the command rpm -Fvh *.rpm and rpm would sift through the packages, upgrading only those that had older versions installed.

Removing packages is much simpler than installing or upgrading them. Issue the command rpm -e packagename to remove it, assuming it would not break any dependencies. Be careful: if you remove a package you did not realize you needed and that has no RPM dependencies, you could easily result in a broken system — after all, RPM only knows about what software requires other software, but it has no idea you depend on OpenOffice.org to write your thesis. To determine if a package is safe to remove, explore it with the query commands shown earlier, especially -qi and -ql.

As you explore installation, sooner or later you will encounter a dependency issue. RPM, by default, will not let you install a package unless everything it depends on is also installed. Unfortunately, as you may have noticed earlier, the dependencies are sometimes not quite obvious because they do not lead to the package name you should use (for example, libc.so.6 is part of the glibc package; not immediately obvious unless you already knew that glibc supplied the standard C libraries and that libc was the name of one of those libraries). To assist in this, RPM itself provides a helping hand. After all, it knows quite a bit about packages... if only it knew about the ones you do not have installed. Fortunately, to a certain degree, it does, with the help of a package called rpmdb-redhat in Red Hat Enterprise Linux or rpmdb-fedora in Fedora Core. Install this package (either via yum, up2date, or from a mirror), and RPM will automatically begin suggesting dependency resolutions as shown in Example 6, “Example of Package Dependencies Suggestion”. This solves a great deal of the trouble involving dependencies, but there are times it fails; most notably are with third party packages that rely on other third party packages. Nonetheless, it is quite useful. 

# rpm -Uvh gaim-0.75-1.3.0.x86_64.rpm
error: Failed dependencies:
        libnss3.so()(64bit) is needed by gaim-0.75-1.3.0
        libnss3.so(NSS_3.2)(64bit) is needed by gaim-0.75-1.3.0
        libnss3.so(NSS_3.3)(64bit) is needed by gaim-0.75-1.3.0
        libsmime3.so()(64bit) is needed by gaim-0.75-1.3.0
        libsoftokn3.so()(64bit) is needed by gaim-0.75-1.3.0
        libssl3.so()(64bit) is needed by gaim-0.75-1.3.0
        libssl3.so(NSS_3.2)(64bit) is needed by gaim-0.75-1.3.0
    Suggested resolutions:
        mozilla-nss-1.4.1-18.x86_64.rpm
Example 6. Example of Package Dependencies Suggestion

Suppose, though, that despite the dependencies, you really want to install a package. RPM offers the dreaded --force and --nodeps parameters to both the installation related modes and the remove mode. They ignore conflicts and dependencies, respectively. Although they do make it easier to get a package installed, very often they result in the package not working, and occasionally they result in other pieces of software also not working. So unless you know exactly what you are doing, and you are fully aware of the consequences of each conflict or dependency you are overriding, do not use these options. To detect cases where this has been used after the fact, rpm -Va --nofiles, mentioned earlier, will report these types of errors. When using --force and --nodeps, though, remember that you are short-circuiting many of RPM's built-in safety features.

Occasionally there will be times that, instead of installing a package, you want to get to one or more files inside of it. Although you often can install a package in these cases, it is not necessarily something you want to do, and, supposing the package had dependencies you can not satisfy, it would not be something you could do without resorting to less savory methods. As mentioned before, RPM packages can be thought of as fancy tarballs or zip files, so it stands to reason that it is possible to extract the contents of a package similar to those file formats. RPM itself gives you no direct way to do this, but it supplies a utility called rpm2cpio that converts a package into what is called a cpio archive (which is even more similar to a tarball). So, to crack open an RPM package, make a directory somewhere, change into this directory, and type rpm2cpio packagename | cpio -id, where packagename is the location of the package file. This results in the contents of the package being extracted into the current directory, at which time you can immediately retrieve the file you sought.

yum, up2date, and redhat-config-packages

Although knowledge of the details of how the rpm command functions is absolutely critical when administering any RPM-based distribution, it can be a bit of a chore to have to download RPMs by hand and perform updates over and over across many boxes. Not only are the simple logistics of copying files and logging into boxes tiring, but when dependencies get involved, it can be very nearly impractical, especially when large numbers of systems are involved. Fortunately this weakness has been addressed in a number of ways, both by the community and by corporations such as Red Hat. Red Hat Enterprise Linux comes with the Red Hat Update Agent (up2date), and Fedora Core ships with two such solutions: yum and up2date.

Yum is one of the brighter stars of Fedora Core. The name, which stands for Yellow Dog Updater, Modified, also reflects its main purpose — ensuring a system is updated with the latest security fixes. One area where yum particularly excels is the integration of multiple sites as sources of packages. In other words, by adding a few lines to a configuration file, you have both the official Fedora Core packages as well as access to any repository created by anyone in the community.

Out of the box, Fedora Core has yum already configured to fetch updates. In fact, one of the first things you should do is determine if there are any updates available and apply them as quickly as possible (and there will always be updates for a freshly installed system... such is the nature of all operating systems in the modern era). To perform this check, type yum check-update. The output will look similar to Example 7, “Example of Package Dependencies Suggestion”.

Gathering header information file(s) from server(s)
Server: Fedora Core 1 - x86_64 - Base
Server: Fedora Core 1 - x86_64 - Released Updates
Finding updated packages
Downloading needed headers
Name                                Arch   Version                  Repo
--------------------------------------------------------------------------------
openssl                             x86_64 0.9.7a-33.10             updates-released
openssl-devel                       x86_64 0.9.7a-33.10             updates-released
Example 7. Example of Package Dependencies Suggestion

Once you have an idea of the newer software available, either update packages a few at a time with the command yum update packagename packagename packagename or perform all updates via the command yum update (not listing any specific packages). Yum will then compute any dependencies, prompt for confirmation, download the packages, verify checksums (which protects from mangled downloads), and, if configured to do so, verify the cryptographic signatures on the package (which protects from maliciously modified packages). Although the download and install processes can take some time, it is vital that critical security updates be applied to your system in a timely matter. In fact, it is highly recommended that users subscribe to the fedora-announce-list to receive alerts of updated packages and security issues, as well as other major announcements from the Fedora community. This list, and several other Fedora-related lists, can be accessed via http://fedora.redhat.com/participate/communicate/.

The Red Hat Update Agent, on the other hand, began life in Red Hat Linux 6.2 and has shipped standard with every subsequent release. (Note that the original version of up2date in RHL 6.2 did not connected to RHN servers. However, updated packages were released in conjunction with RHN to allow RHL 6.2 users to retrieve updates via RHN.) It is also the supported update mechanism for Red Hat Enterprise Linux. The usage of both the command line and graphical interfaces are very similar between Red Hat Enterprise Linux and Fedora Core, but one notable difference is that, in Red Hat Enterprise Linux, up2date asks you to create an account. It is important to use the same account to register your system with up2date as you used when you activated or purchased your Red Hat Enterprise Linux system. One of the advantages of up2date in this circumstance is that, since your system is a registered Red Hat Enterprise Linux installation, priority bandwidth is used to service your requests; therefore, it is not necessary to find mirrors, change configuration files, or other avenues that may be necessary when using yum or up2date in Fedora Core. Beginning with FC1, up2date can function either in the traditional mode of connecting directly to Red Hat servers speaking an up2date-specific protocol or to yum servers speaking the yum protocol (actually, it can speak a number of other protocols, most notably apt, but as yum is the standard, it is what we will cover here). Although up2date and yum largely support the same set of features, some users are historically more comfortable with up2date or find some of up2date's more advanced features useful. Also, up2date provides a friendly graphical interface for downloading and installing updates, which is preferable for some users over command line utilities like yum.

In Fedora Core, by default, up2date, like yum, is also configured to speak to the official Fedora servers to get updates. Likewise, in Red Hat Enterprise Linux, up2date is configured to speak to the dedicated Red Hat Network servers for priority bandwidth. Execute the command up2date or select System Tools -> Red Hat Network from the Main Menu on the panel to list the available updates and follow the graphical wizard through the various steps. Or, if you prefer the command line, the command up2date -l gives similar output to yum check-update but in a different format, and up2date -u updates all packages without prompting, satisfying dependencies along the way. Note that by default, up2date will not upgrade kernels; this is largely a leftover from the past when it was not as reliable to perform automated kernel upgrades. These days, it is quite safe and so you should either consider editing up2date's exclude list (via up2date –configure, and then clicking on the Exclusions tab) or using the -f modifier on the up2date -u command line; this will override package exclusions for that single invocation, allowing a kernel to be installed.

One of the great features of yum and up2date is that they allow for external repositories of packages. There are scores of these repositories, ranging from tiny repositories for specific projects (such as Arjan van de Ven's kernel 2.6 repository) to large, encompassing repositories of extra software such as the popular freshrpms.net or even the original fedora.us repository (which is the foundation of what became the Fedora Project). Adding a repository is different between up2date and yum, but you need the same information for both — the URL of the repository in question.

To add a repository to yum, edit the /etc/yum.conf file. In it are several sections, labeled with the name in brackets. The first section is [main] and contains a number of different settings for yum itself; best to ignore it for now, although the yum man page goes into details on the settings. The next section is [base] which corresponds to the repository containing the packages that shipped originally with Fedora Core 1. This is here to satisfy dependencies and allow for easy installation of packages in the base. In this section are two entries, name and baseurl. These are required for every section besides [main] and are exactly what they sound like — a descriptive name of the repository and the base URL of the repository. Also present is an [updates-released] section, which contains official releases, and an [updates-testing] section that is commented out (uncomment it to help test updated packages, but beware, as with all pre-release software, breakages will occasionally happen). So, assuming you have the URL for a repository to add, add a new section at the bottom of the file, named [repository] (where repository is a suitably creative name for the repository in question but is your choice) and add a name= to describe the repository. Then add a baseurl= to map to the URL you already have, save the file, and run yum check-update to see if it works.

up2date is similar, but the file in question is /etc/sysconfig/rhn/sources and not /etc/yum.conf. There should be a number of examples in this file; search for fedora-core-1 to see the entry for the base OS itself, similar to the [main] section in yum.conf. Here, however, every repository is a single line, prefixed by the repository type (which should be yum in this case), followed by a descriptive label (the same idea as the bracketed labels for yum.conf) and the URL to the repository. Save your changes and run up2date -l to see if you are successful.

Now that you have yum and/or up2date configured to include your favorite repositories, you can begin to see what software is available. To list all of the available packages via yum, type yum list. To view a similar list from up2date, use the command up2date --showall.

Sometimes, though, you do not want to download large programs to install them, or you are not exactly sure what program you want. There is a third utility, the newest of the three, called redhat-config-packages. Although the name is a bit peculiar, it serves a very important function. It knows what software Red Hat Enterprise Linux and Fedora Core shipped with, what CD it is on, and lets you choose packages not by the name directly but instead based upon the same categorization you may have seen in the installation program. This is much more intuitive since it lets you quickly find the program you want without having to already know its name. Figure 1, “redhat-config-packages” shows the list of categories available. Selecting a package is as simple as selecting a category, clicking a few check boxes, and pressing the Update button. You are then prompted to insert the appropriate CD to install the packages and any missing dependencies they may have.

redhat-config-packages
Figure 1. redhat-config-packages

Conclusion

Hopefully this article has provided a good overview of both RPM itself and the utilities around it. Although a rich and deep subject, productive use is only a few commands away, especially once you know the secrets of how the innards of RPM work. The best way to learn more, besides experimenting directly, is to get involved with the Fedora community. There are a number of mailing lists, most notably fedora-list, that are aimed at general users of Fedora and that can help with Fedora-specific questions. To join it or any other Linux-related lists, go to the Red Hat mailing list server at http://listman.redhat.com/. There is also a list for RPM itself that has an active and helpful community, also available from the Red Hat mailing list server.

In part 2 of this article, we will explore the next level in mastering RPM — creating your own RPM packages. Although not necessarily immediately obvious, once you know how to create packages, the flexibility, reliability, and predictability gained from properly packaging software will quickly become a time saver and make dealing with RPM-based Linux distributions much easier.

About the Author

Chip Turner has been with Red Hat for three years and is the Lead Architect for Red Hat Network. He also maintains the perl package, all perl modules, and spamassassin for Fedora Core and Red Hat Enterprise Linux as well as authors the RPM2 perl bindings for RPM and a handful of other CPAN perl modules. In his spare time he enjoys playing with his dog and arguing for no apparent point.