The RPM spec file is divided into two main parts: the package information tags, such as the name of the package, and the build section, such as the commands to compile the software.
22.1. Package Information Tags
The package information tags contain most of the header tags that you can query with the rpm command. First and foremost, this includes a name.
The name-epoch-version-release tags, which form the NEVR used to identify packages, should all appear in your spec file, although you can skip the Epoch tag.
Name: name
# Epoch: 1
Version: version_number
Release: package_release_number
The optional Epoch tag provides an ordering for the version numbers (replacing the deprecated Serial tag). Use this tag if RPM cannot figure out the ordering of which release comes after another.
Epoch: 42
A number of tags allow you to define who made the package and under what conditions has the package been released:
Vendor: name_of_vendor
URL: URL_to_package_home
Copyright: package_copyright_message
Distribution: Linux_or_product_distribution
Packager: John Q. Smith <john.smith@somecompany.yow>
Group: group_for_categorizing_package
Use the Group tag to help users categorize your package.
The Icon tag allows you to provide a desktop icon for the package:
Icon: filename.xpm
A one-line summary is essential to tell users what your package is for:
Summary: one_line_description_of_package
You should also include a longer description section, marked by %description:
%description
Tcsh is an enhanced but completely compatible version of csh, the C
shell. Tcsh is a command language interpreter which can be used both
as an interactive login shell and as a shell script command processor.
Tcsh includes a command line editor, programmable word completion,
spelling correction, a history mechanism, job control and a C language
like syntax.
In the description section, blank lines indicate paragraphs. Lines that start with a space are not formatted.
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 used mostly to help explain your syntax choices to yourself should you view the spec file later.
Note
The BuildArchitectures tag names the architectures that a binary RPM will run on. See
Chapter 20, Customizing RPM Behavior for a description of the architecture settings. A special value of noarch indicates a package that is not dependent on a particular architecture, such as a Perl or Python script.
The BuildPreReq tag lists any prerequisites for building. For example:
BuildPreReq: ncurses-devel
The Buildroot tag names the temporary directory in which to build the package. For example:
Buildroot: %{_tmppath}/%{name}-root
For each dependency, you can specify a capability name alone. For example:
Provides: capability_name
You can also provide a particular version number or indicate that your package has a dependency on a version larger or smaller than a given number. For example:
Requires: capability_name >= version_number
Requires: capability_name <= version_number
Requires: capability_name > version_number
Requires: capability_name < version_number
Requires: capability_name == version_number
Requires: capability_name = version_number
The == and = act the same for dependencies. Both check for a version equal to the given number. You can provide multiple items, separated by commas. For example:
Requires: python >= 1.3, perl
For add-on modules for interpreters, especially Perl, you can use the following syntax to define capabilities:
Provides: perl(MIME-Base64)
This example provides the MIME-Base64 add-on Perl module.
You can also use or to specify more than one possibility. For example:
perl(IO-Wrap) == 4.5 or perl(IO-Wrap)-4.5
The Provides, Requires, Obsoletes, and Conflicts dependency tags all work the same for capability names and version numbers.
Note
You can also specify BuildRequires tags for capabilities necessary to build the package, not to install it. A BuildConflicts tag names capabilities that conflict for building, such as a particular version of the gcc C compiler.
The source and patch tags identify the source files used to build the binary package. The patch tags identify any patches used to modify the sources.
If you have more than one of a particular kind of tag, append a number. For example:
Source0: ftp://ftp.uk.linux.org/pub/linux/telnet-%{telnet_version}.tar.gz
Source2: telnet-client.tar.gz
Source3: telnet-xinetd
Source4: telnet.wmconfig
Patch1: telnet-client-cvs.patch
Patch5: telnetd-0.17.diff
Patch6: telnet-0.17-env.patch
Patch7: telnet-0.17-issue.patch
Patch8: telnet-0.17-sa-01-49.patch
Patch9: telnet-0.17-env-5x.patch
Patch10: telnet-0.17-pek.patch
