3.4. What is a SPEC file

You can understand a SPEC file as a recipe that the rpmbuild utility uses to build an RPM. A SPEC file provides necessary information to the build system by defining instructions in a series of sections. The sections are defined in the Preamble and the Body part. The Preamble part contains a series of metadata items that are used in the Body part. The Body part represents the main part of the instructions.

The following sections describe each section of a SPEC file.

3.4.1. Preamble items

The table below presents some of the directives that are used frequently in the Preamble section of the RPM SPEC file.

Tableau 3.1. Items used in the Preamble section of the RPM SPEC file

SPEC DirectiveDéfinition


The base name of the package, which should match the SPEC file name.


The upstream version number of the software.


The number of times this version of the software was released. Normally, set the initial value to 1%{?dist}, and increment it with each new release of the package. Reset to 1 when a new Version of the software is built.


A brief, one-line summary of the package.


The license of the software being packaged.


The full URL for more information about the program. Most often this is the upstream project website for the software being packaged.


Path or URL to the compressed archive of the upstream source code (unpatched, patches are handled elsewhere). This should point to an accessible and reliable storage of the archive, for example, the upstream page and not the packager’s local storage. If needed, more SourceX directives can be added, incrementing the number each time, for example: Source1, Source2, Source3, and so on.


The name of the first patch to apply to the source code if necessary.

The directive can be applied in two ways: with or without numbers at the end of Patch.

If no number is given, one is assigned to the entry internally. It is also possible to give the numbers explicitly using Patch0, Patch1, Patch2, Patch3, and so on.

These patches can be applied one by one using the %patch0, %patch1, %patch2 macro and so on. The macros are applied within the %prep directive in the Body section of the RPM SPEC file. Alternatively, you can use the %autopatch macro which automatically applies all patches in the order they are given in the SPEC file.


If the package is not architecture dependent, for example, if written entirely in an interpreted programming language, set this to BuildArch: noarch. If not set, the package automatically inherits the Architecture of the machine on which it is built, for example x86_64.


A comma or whitespace-separated list of packages required for building the program written in a compiled language. There can be multiple entries of BuildRequires, each on its own line in the SPEC file.


A comma- or whitespace-separated list of packages required by the software to run once installed. There can be multiple entries of Requires, each on its own line in the SPEC file.


If a piece of software can not operate on a specific processor architecture, you can exclude that architecture here.


Conflicts are inverse to Requires. If there is a package matching Conflicts, the package cannot be installed independently on whether the Conflict tag is on the package that has already been installed or on a package that is going to be installed.


This directive alters the way updates work depending on whether the rpm command is used directly on the command line or the update is performed by an updates or dependency solver. When used on a command line, RPM removes all packages matching obsoletes of packages being installed. When using an update or dependency resolver, packages containing matching Obsoletes: are added as updates and replace the matching packages.


If Provides is added to a package, the package can be referred to by dependencies other than its name.

The Name, Version, and Release directives comprise the file name of the RPM package. RPM package maintainers and system administrators often call these three directives N-V-R or NVR, because RPM package filenames have the NAME-VERSION-RELEASE format.

The following example shows how to obtain the NVR information for a specific package by querying the rpm command.

Exemple 3.1. Querying rpm to provide the NVR information for the bash package

# rpm -q bash

Here, bash is the package name, 4.4.19 is the version, and 7.el8 is the release. The final marker is x86_64, which signals the architecture. Unlike the NVR, the architecture marker is not under direct control of the RPM packager, but is defined by the rpmbuild build environment. The exception to this is the architecture-independent noarch package.

3.4.2. Body items

The items used in the Body section of the RPM SPEC file are listed in the table below.

Tableau 3.2. Items used in the Body section of the RPM SPEC file

SPEC DirectiveDéfinition


A full description of the software packaged in the RPM. This description can span multiple lines and can be broken into paragraphs.


Command or series of commands to prepare the software to be built, for example, unpacking the archive in Source0. This directive can contain a shell script.


Command or series of commands for building the software into machine code (for compiled languages) or byte code (for some interpreted languages).


Command or series of commands for copying the desired build artifacts from the %builddir (where the build happens) to the %buildroot directory (which contains the directory structure with the files to be packaged). This usually means copying files from ~/rpmbuild/BUILD to ~/rpmbuild/BUILDROOT and creating the necessary directories in ~/rpmbuild/BUILDROOT. This is only run when creating a package, not when the end-user installs the package. See Working with SPEC files

for details.


Command or series of commands to test the software. This normally includes things such as unit tests.


The list of files that will be insstalled in the end user’s system.


A record of changes that have happened to the package between different Version or Release builds.

3.4.3. Advanced items

The SPEC file can also contain advanced items, such as Scriptlets

or Triggers.

They take effect at different points during the installation process on the end user’s system, not the build process.