Chapter 13

Inside the Spec File

In this chapter, we're going to cover the spec file in detail. There are a number of different types of entries that comprise a spec file, and every one will be documented here. The different types of entries are

• Comments—Human-readable notes ignored by RPM.
• Tags—Data definitions.
• Scripts—A set of commands to be executed at specific times.
• Macros—A method of executing multiple commands easily.
• The %files list—A list of files to be included in the package.
• Directives—Used in the %files list to direct RPM to handle certain files in a specific way.
• Conditionals—Permit operating system_ or architecture-specific preprocessing of the spec file.

Let's start by looking at comments.

13.1. Comments: Notes Ignored by RPM

Comments are a way to make RPM ignore a line in the spec file. The contents of a comment line are entirely up to the person writing the spec file.

To create a comment, enter an pound sign (#) at the start of the line. Any text following the comment character will be ignored by RPM. Here's an example of a comment:

# This is the spec file for playmidi 2.3...

Comments can be placed in any section of the spec file.

13.2. Tags: Data Definitions

Looking at a spec file, the first thing you'll see are a number of lines, all following the same basic format:

<something>:<something-else>

<something> is known as a tag because it is used by RPM to name or tag some data. The tag is separated from its associated data by a colon. The data is represented by <something-else>. Tags are grouped together at the top of the spec file, in a section known as the preamble. Here's an example of a tag and its data:

Vendor: White Socks Software, Inc.

In this example, the tag is Vendor. Tags are not case sensitive—they may be all uppercase, all lowercase, or anything in between. The Vendor tag is used to define the name of the organization

producing the package. The data in this example is White Socks Software, Inc.. Therefore, RPM will store White Socks Software, Inc. as the vendor of the package.

Note also that spacing between the tag, the colon, and the data is unimportant. Given this, and the case insensitivity of the tag, each of the following lines is equivalent to the previous example:

VeNdOr : White Socks Software, Inc.



vendor:White Socks Software, Inc.



VENDOR : White Socks Software, Inc.

The bottom line is that you can make tag lines as neat or as ugly as you like—RPM won't mind either way. Note, however, that the tag's data might need to be formatted in a particular fashion. If there are any such restrictions, we'll mention them. The following sections group together tags of similar functions for easier reference, starting with the tags used to create the package name.

13.2.1. Package Naming Tags

The following tags are used by RPM to produce the package's final name. Since the name is always in this format:

<name>-<version>-<release>

it's only natural that the three tags are known as name, version, and release.

The name tag is used to define the name of the software being packaged. In most (if not all) cases, the name used for a package should be identical in spelling and case to the software being packaged. The name cannot contain any whitespace: If it does, RPM will only use the first part of the name (up to the first space). Therefore, if the name of the software being packaged is cdplayer, the name tag should be something like this:

Name: cdplayer

The version tag defines the version of the software being packaged. The version specified should be as close as possible to the format of the original software's version. In most cases, there should be no problem specifying the version just as the software's original developer did. However, there is a restriction: There can be no dashes in the version. If you forget, RPM will remind you:

# rpm -ba cdplayer-1.0.spec

Package: cdplayer

Illegal `-' char in version: 1.0-a

#

Spaces in the version will also cause problems, in that anything after the first space will be ignored by RPM. The bottom line is that you should stick with alphanumeric characters and periods, and you'll never have to worry about it. Here's a sample version tag:

Version: 1.2

The release tag can be thought of as the package's version. The release is traditionally an integer—for example, when a specific piece of software at a particular version is first packaged, the release should be 1. If it is necessary to repackage that software at the same version, the release should be incremented. When a new version of the software becomes available, the release should drop back to 1 when it is first packaged.

Note that we used the word traditionally. The only hard-and-fast restriction to the release format is that there can be no dashes in it. Be aware that if you buck tradition, your users may not understand what your release means.

It is up to the package builder to determine which build represents a new release and to update the release manually. Here is what a typical release tag might look like:

Release: 5

13.2.2. Descriptive Tags

Descriptive tags provide information primarily for people who want to know a bit more about the package and who produced it. They are part of the package file, and most of them can be seen by issuing an rpm -qi command.

The %description tag is used to provide an in-depth description of the packaged software. The description should be several sentences describing, to an uninformed user, what the software does.

The %description tag is a bit different from the other tags in the preamble. For one, it starts with a percent sign. The other difference is that the data specified by the %description tag can span more than one line. In addition, a primitive formatting capability exists. If a line starts with a space, that line will be displayed verbatim by RPM. Lines that do not start with a space are assumed to be part of a paragraph and will be formatted by RPM. It's even possible to mix and match formatted and unformatted lines. Here are some examples:

%description

It slices! It dices! It's a CD player app that can't be beat. By using the

resonant frequency of the CD itself, it is able to simulate 20X

oversampling. This leads to sound quality that cannot be equaled with more

mundane software...