The nosource tag is used to direct RPM to omit one or more source files from the source package. Why would someone want to go to the trouble of specifying a source file, only to exclude it? The reasons for this can be varied, but let's look at one example: The software known as pretty good privacy, or PGP.

PGP contains encryption routines of such high quality that the U.S. government restricts their export. (There is also an international version that may be used in non-U.S. countries. See Appendix G, "An Introduction to PGP.") While it would be nice to create a PGP package file, the resulting package could not legally be transferred between the U.S. and other countries.

However, what if all files other than the original source were packaged using RPM? Well, a binary package made without PGP would be of little use, but what about the source package? It would contain the spec file, maybe some patches, and perhaps even an icon file. Since the controversial PGP software was not a part of the source package, this sanitized source package could be downloaded legally in any country. The person who downloaded a copy could then go about legally obtaining the PGP sources himself, place them in RPM's SOURCES directory, and create a binary package. He wouldn't even need to change the nosource tag. One rpm -ba command later, and the user would have a perfectly usable PGP binary package file.

Since there may be more than one source tag in a spec file, the format of the nosource tag is as follows:

nosource: <src-num>, <src-num>...<src-num>

<src-num> represents the number following the source tag. If there is more than one number in the list, the numbers may be separated by either commas or spaces. For example, consider a package containing the following source tags:

source: blather-4.5.tar.gz

Source1: bother-1.2.tar.gz

source2: blather-lib-4.5.tar.gz

source3: bother-lib-1.2.tar.gz

If the source files for blather and blather-lib were not to be included in the package, the following nosource line could be added:

NoSource: 0, 3

What about that 0? Keep in mind that the first unnumbered source tag in a spec file is automatically numbered 0 by RPM.

The patch tag is used to identify which patches are associated with the software being packaged. The patch files are kept in RPM's SOURCES directory, so only the name of the patch file should be specified. Here is an example:

Patch: cdp-0.33-fsstnd.patch

There are no hard-and-fast requirements for naming the patch files, but traditionally the filename starts with the software name and version, separated by dashes. The next part of the patch file name usually includes one or more words indicating the reason for the patch. In the preceding example, the patch file contains changes necessary to bring the software into compliance with the Linux File System Standard, hence the fsstnd magic incantation.

RPM processes patch tags the same way it does source tags. Therefore, it's acceptable to use a URL on a patch line, too.

A spec file may contain more than one patch tag. This is necessary for those cases where the software being packaged requires more than one patch. However, the patch tags must be uniquely identified. This is done by appending a number to the end of the tag itself. In fact, RPM does this internally for the first patch tag in a spec file, in essence turning it into patch0. Therefore, if a package contains three patches, this method of specifying them:

Patch: blather-4.5-bugfix.patch

Patch1: blather-4.5-config.patch

Patch2: blather-4.5-somethingelse.patch

is equivalent to this one:

Patch0: blather-4.5-bugfix.patch

Patch1: blather-4.5-config.patch

Patch2: blather-4.5-somethingelse.patch

Either approach may be used, but the second method looks nicer.

The nopatch tag is similar to the nosource tag discussed earlier. Just like the nosource tag, the nopatch tag is used to direct RPM to omit something from the source package. In the case of nosource, that something was one or more sources. For the nopatch tag, the something is one or more patches.

Since each patch tag in a spec file must be numbered, the nopatch tag uses those numbers to specify which patches are not to be included in the package. The nopatch tag is used in this manner:

NoPatch: 2 3

In this example, the source files specified on the source2 and source3 lines are not to be included in the build.

This concludes our study of RPM's tags. In the next section, we'll look at the various scripts that RPM uses to build, as well as to install and erase, packages.

13.3. Scripts: RPM's Workhorse

The scripts that RPM uses to control the build process are among the most varied and interesting parts of the spec file. Many spec files also contain scripts that perform a variety of tasks whenever the package is installed or erased.

The start of each script is denoted by a keyword. For example, the %build keyword marks the start of the script RPM will execute when building the software to be packaged. Note that, in the strictest sense of the word, these parts of the spec file are not scripts. For example, they do not start with the traditional invocation of a shell. However, the contents of each script section are copied into a file and executed by RPM as a full-fledged script. This is part of the power of RPM: Anything that can be done in a script can be done by RPM.

Let's start by looking at the scripts used during the build process.

13.3.1. Build-Time Scripts

The scripts that RPM uses during the building of a package follow the steps known to every software developer:

1. Unpack the sources.
2. Build the software.
3. Install the software.
4. Clean up.

Although each of the scripts performs a specific function in the build process, they share a common environment. Using RPM's --test option (described in section 12.1.11 in Chapter 12), we can see the common portion of each script. In the following example, we've taken the cdplayer package, issued an rpm -ba --test cdplayer-1.0-1.spec, and viewed the script files left in RPM's temporary directory. This section (with the appropriate package-specific values) is present in every script RPM executes during a build:

#!/bin/sh -e

# Script generated by rpm



RPM_SOURCE_DIR="/usr/src/redhat/SOURCES"

RPM_BUILD_DIR="/usr/src/redhat/BUILD"

RPM_DOC_DIR="/usr/doc"

RPM_OPT_FLAGS="-O2 -m486 -fno-strength-reduce"

RPM_ARCH="i386"

RPM_OS="Linux"

RPM_ROOT_DIR="/tmp/cdplayer"

RPM_BUILD_ROOT="/tmp/cdplayer"

RPM_PACKAGE_NAME="cdplayer"

RPM_PACKAGE_VERSION="1.0"

RPM_PACKAGE_RELEASE="1"

set -x



umask 022