Most of the package information you need to enter into a spec file fleshes out the information you can query for a given package, such as the name, version, and release information, along with a longer description and a one-line summary.
This gets a little more complicated when you set build locations, name source files, and name patches. The following section cover how to specify the package information.
9.3.1. Describing the package
The first part of the spec file defines macros (covered in the section "Defining Spec File Macros"), and describes the package. Starting with the basics, you need a name, version, and release. You also should provide a longer description. For legal reasons, you may need to include ownership and copyright information.
9.3.1.1. Naming the Package
The most important part of the package description is the NVR, or Name-Version-Release information, because this information is so crucial for the RPM system to compare versions and track dependencies.
Set the name with the Name: directive. For example:
Name: myapp
The name should not contain any spaces or other whitespace characters such as tabs or newlines. Remember, RPM files are named, by default, name-version-release.rpm, or name-version-release-architecture.rpm, so use valid characters for file names.
The version number is used in version comparisons. The RPM comparison algorithm is fairly complex, but can get fooled by strange version numbers. So, your best bet is to stick to dotted numerics, such as 1.5 or 2.3.1.1.4 or 1.0. Version numbers such as these will compare best from within the RPM system. For example:
Version: 1.1.2
You cannot use a dash in the version number, as RPM uses the dash to separate the Name-Version-Release elements. You can use a dash in the package name, though.
The release number should start at 1 for the first RPM you build for a given version of the package, and count up from there. For example:
Release: 1
The release differentiates newer updates of the RPM itself, even if the underlying application hasn’t changed. (The application may be compiled with different compiler options, though.) For most usage, simply start at 1 and each time you modify the spec file and recreate the package, increment the release number.
If the version number is not enough to allow for comparisons, for example, if the version numbering scheme has changed radically between releases, you can define an Epoch: directive. For example:
Epoch: 3
If you renumber your versions, use an Epoch setting to clarify the version history. For example, Sun Microsystems went from SunOS 4.1 to Solaris 2. The Epoch: helps RPM properly handle strange version number changes. Define the Epoch: as a whole number such as 1, 2, or 3.
Warning
Avoid using the Epoch: directive if at all possible. It is far better to use a sane version-numbering scheme than to try to resolve the mess with epoch values. The main problems with using an epoch value are that epochs are hidden from users in most cases, and using epochs can lead to very strange-looking tasks such as a newer package with a version number that looks older than the older package.
The older Serial: directive also works similarly to the Epoch: directive. For example:
Serial: 6
Like the Epoch:, the Serial: directive should be a number that counts upward. Modern packages should use the Epoch: directive instead of Serial:, since Serial: has been deprecated for many, many rpm versions.
The Group: directive provides a classification for your packages. If at all possible, use a category name that already exists for other packages, such as System Environment/Shells for a Linux shell. For example:
Group: System Environment/Shells
Many graphical installation tools divide packages by these categories, so you want to fit into the existing group names if possible. (See
Chapter 4, Using the RPM Database for more on querying group information from RPMs.) The official list of groups are located in the file /usr/share/doc/rpm-4.1/GROUPS for RPM 4.1, and in a similar location for other RPM versions.
The Distribution: directive is used by Linux distribution vendors such as Red Hat to identify that the package is part of a given distribution, or was built for a particular distribution. Most packages created outside of the Linux vendors don’t provide this directive.
Distribution: Red Hat Linux
The Icon: directive names an icon file stored in the RPM. The file format should be XPM or GIF, with an extension of .xpm or .gif, respectively. Some packaging tools will use this icon in a package display.
9.3.1.2. Specifying Company Information
For legal reasons, you probably want to specify the organization behind the RPM, any copyright or licensing information, as well as a URL to find out more information. Even if you are not concerned about corporate legal issues, you may want to identify where the package came from. Use the following directives to provide this information.
The Vendor: directive names the company or organization behind an RPM. For example:
Vendor: The Really Cool Company
The URL: directive provides a URL to your company or organization home page, or perhaps to a URL for a particular application. For example:
URL: http://mycompany.yow/products/coolstuff
Similarly, the Packager: directive provides an optional name and e-mail address for the person who created the RPM:
Packager: Bob Marley <marley@reggae.com>
The License: and Copyright: directives provide legal information about your package. Older packages tended to use Copyright: as a statement of the package’s license, not copyright. For example:
Copyright: BSD
License: LGPL
Warning
The Copyright: directive is deprecated in favor of License:.
9.3.1.3. Filling in the Description
The Summary: directive provides a one-line short description of the package. You should not exceed much more than 50 characters when writing your summary. For example:
Summary: A program that does exactly what you want
Note
The Summary: directive of the spec file replaces the older Description: directive.
The %description section allows for longer text describing your package. Fill in as many lines as you need after the %description section. For example:
%description
This is a really cool package. It contains the really cool
program that provides a maximum return on investment,
or ROI, for achieving your crucial business objectives
utilizing world-class high-caliber componentized software
implemented with world-class quality and performance
metrics.
The %description section supports a limited amount of formatting. Blank lines are assumed to separate paragraphs. Some graphical user interface installation programs will reformat paragraphs into a nicer-looking font and change the display width.
Lines in the %description section that start with whitespace, such as a space or tab, will be treated as preformatted text and displayed as is, normally with a fixed-width font. The rpm command supports text formatting this way. Other rpm programs may not.
9.3.1.4. Specifying the Platform Architecture
Spec files can announce that a package can run on more than one operating system or is tied to a particular version of a particular operating system.
For example, the Excludearch: directive states that a package should not be built on the given architecture or architectures. For example:
ExcludeArch: sparc s390 s390x
This example excludes the SPARC and S/390 mainframe architectures. You can provide more than one architecture in the directive, separated by spaces or commas.
Similarly, the Exclusivearch: directive states that a package can only be built on the given architecture or architectures. For example:
ExclusiveArch: i386 ia64 alpha
This example identifies the package as only working on the Intel i386, IA-64, and Alpha architectures.
The Excludeos: and Exclusiveos: directives restrict the operating system. For example:
Excludeos: windows
This example states that the package should not be built on Windows. In contrast, the Exclusiveos: directive names only the operating system or systems that the package can be built on. For example:
Exclusiveos: linux
Cross Reference