In this example, RPM would not attempt to build the package on either the Sun SPARC or Digital Alpha/AXP architectures. The package could build on any other architectures, however. If a build is attempted on an excluded architecture, the following message will be displayed, and the build will fail:

# rpm -ba cdplayer-1.0.spec

Arch mismatch!

cdplayer-1.0.spec doesn't build on this architecture

#

Note that if your goal is to ensure that a package will only build on one architecture, you should use the exclusivearch tag.

The exclusivearch tag is used to direct RPM to ensure that the package is only built on the specified architecture(s). The reasons for this are similar to the those mentioned in section 13.2.5.1. However, the exclusivearch tag is useful when the package builder needs to ensure that only the specified architectures will build the package. This tag ensures that no future architectures will mistakenly attempt to build the package. This would not be the case if the excludearch tag were used to specify every architecture known at the time the package is built.

The syntax of the exclusivearch tag is identical to that of excludearch:

ExclusiveArch: sparc alpha

In this example, the package will only build on a Sun SPARC or Digital Alpha/AXP system.

Note that if your goal is to ensure that a package will not build on specific architectures, you should use the excludearch tag.

The excludeos tag is used to direct RPM to ensure that the package does not attempt to build on the excluded operating system(s). This is usually necessary when a package is to be built on more than one operating system, but it is necessary to keep a particular operating system from attempting a build.

Note that if your goal is to ensure that a package will only build on one operating system, you should use the exclusiveos tag. Here's a sample excludeos tag:

ExcludeOS: linux irix

The exclusiveos tag has the same syntax as excludeos, but it has the opposite logic. The exclusiveos tag is used to denote which operating system(s) should be exclusively permitted to build the package. Here's exclusiveos in action:

ExclusiveOS: linux

Note that if your goal is to ensure that a package will not build on a specific operating system, you should use the excludeos tag.

13.2.5. Directory-Related Tags

A number of tags are used to specify directories and paths that are used in various phases of RPM's build and install processes. There's not much more to say collectively about these tags, so let's dive right in and look them over.

The prefix tag is used when a relocatable package is to be built. A relocatable package can be installed normally or can be installed in a user-specified directory, by using RPM's --prefix install-time option. The data specified after the prefix tag should be the part of the package's path that may be changed during installation. For example, if the following prefix line were included in a spec file:

Prefix: /opt

and the following file were specified in the spec file's %files list:

/opt/blather/foonly

then the file foonly would be installed in /opt/blather if the package was installed normally. It would be installed in /usr/local/blather if the package was installed with the --prefix /usr/local option.

For more information about creating relocatable packages, see Chapter 15, "Making a Relocatable Package."

The buildroot tag is used to define an alternate build root. The name is a bit misleading because the build root is actually used when the software is installed during the build process. In order for a build root to be defined and actually used, a number of issues must be taken into account. These issues are covered in Chapter 16, "Making a Package That Can Build Anywhere." This is what a buildroot tag would look like:

BuildRoot: /tmp/cdplayer

The buildroot tag can be overridden at build time by using the --buildroot command-line option.

13.2.6. Source and Patch Tags

In order to build and package software, RPM needs to know where to find the original sources. But it's not quite that simple. There might be more than one set of sources that need to be part of a particular build. In some cases, it might be necessary to prevent some sources from being packaged.

And then there is the matter of patches. It's likely that changes will need to be made to the sources, so it's necessary to specify a patch file. But the same issues that apply to source specifications are also applicable to patches. There might be more than one set of patches required.

The tags that are described in the following sections are crucial to RPM, so it pays to have a firm grasp of how they are used.

The source tag is central to nearly every spec file. Although it has only one piece of data associated with it, it performs two functions:

• It shows where the software's developer has made the original sources available.
• It gives RPM the name of the original source file.

While there is no hard-and-fast rule for the first function, it's generally considered best to put this information in the form of a URL. The URL should point directly to the source file itself. This is because of the source tag's second function.

As mentioned previously, the source tag also needs to direct RPM to the source file on the build system. How does it do this? There's only one requirement, and it is ironclad: The source filename must be at the end of the line as the final element in a path. Here's an example:

Source: ftp://ftp.gnomovision.com/pub/cdplayer-1.0.tgz

Given this source line, RPM will search its SOURCES directory for cdplayer-1.0.tgz. Everything prior to the filename is ignored by RPM. It's there strictly for any interested humans.

A spec file may contain more than one source tag. This is necessary for those cases where the software being packaged is contained in more than one source file. However, the source 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 source tag in a spec file, in essence turning it into source0. Therefore, if a package contains two source files, they may either be specified this way:

Source: blather-4.5.tar.gz

Source1: bother-1.2.tar.gz

or this way:

Source0: blather-4.5.tar.gz

Source1: bother-1.2.tar.gz