Spec files are text files containing RPM directives. These directives use a simple syntax of a tag name, a colon, and a value:
TagName: value
For example:
Version: 1.15
This example sets the package version to 1.15. The name of the item is not case sensitive, so tag names of version, Version, or VERSION all set the same value. This syntax works for most settings, including Name, Release, and so on.
In addition to this directive syntax, you can define macros using the RPM %define syntax. For example:
%define major 2
This example defines a macro named major with a value of 2. Once defined, you can access macros using the %{macro_name} or just %macro_name syntaxes. For example:
source: %{name}-%{version}.tar.gz
See the section "Defining Spec File Macros" later in this chapter for more options for macros.
Major sections in the spec file are also delimited with % markers. For example, the build section starts with %build on a line by itself.
Note
The multiple uses of the % sign aren’t really that confusing in practice. Read through some spec files and you should find most of the commands are easily understood.
Blank lines separate sections in the spec file, which makes sense for readability as well.
To help document your work, you can include comments (to yourself and others reading the spec file). Any line starting with a hash character, #, holds a comment. RPM will ignore comments.
# This is a comment.
In spec files, comments are mostly to help explain your syntax choices to yourself should you view the spec file later. Comments are a good thing. You should comment heavily, especially for any choice that deviates from the norm. For example, if you provide special C compiler options for building the package, add comments to describe why you picked the options and how necessary they are. Such comments help immensely should you need to port the RPM to another architecture or modify how it was built.
Tip
Avoid single percent signs, %, in comments. For example:
# Added new commands to %prep
The rpmbuild command may report an error of a second %prep section. To get around this problem, use two percent signs, such as %%prep, in spec file comments.
As discussed in Chapter 9, the rpmbuild command expands source RPMs to the /usr/src/redhat directory. Under this directory, the RPM system assumes five subdirectories, listed in Table 10-1.
Table 10-1 Default RPM directories
Directory | Usage |
BUILD | Where the rpmbuild command builds software |
RPMS | Where the rpmbuild command stores binary RPMs it creates |
SOURCES | Where you should put the sources for the application |
SPECS | Where you should place the spec file |
SRPMS | Where the rpmbuild command places source RPMs |
The spec files you create should be stored in the SPECS directory while building RPMs. (You can store your spec files permanently in any location you desire.)
Cross Reference
These directories are the default directories. See Chapter 21 for changing RPM default values. In addition, these are the defaults for Red Hat Linux. See Chapters 19 and 20 for discussions on other versions of Linux and other non-Linux operating systems, respectively.
With the knowledge of the spec file syntax covered in the preceding sections, you can start to write spec files. The first step is to define the basic package information.