RPM spec File Contents

A spec file is the file that contains metadata and scripting necessary to build an RPM. In essence, it defines the RPM.

Basic Sections

1. preamble - basic metadata, including:
   • Name - name of the software package (e.g., "bash")
   • Epoch - the era of the software (optional, and rarely used). See ENVR
   • Version - version of the software, as identified by the software source (1.5)
   • Release - release of the package, as identified by the packager (1, 2, 3, ...; or 1.fc16; or 1.ct)
   • Summary - a one-line description of the software (avoid trailing periods)
   • Group - software group (general classification of the package) - see /usr/share/doc/rpm-*/GROUPS for a list of valid group names
   • License - the license under which the package is provided (GPLv2, GPLv2+, GPLv3, GPLv3+, BSD, ASL, MSL, ...)
   • URL - the web location of the package's main site
   • Source (Source0, Source1, ...) - the URL (preferred) of the source package. The filename portion of the Source must match the filename present in the ~/rpmbuild/SOURCES directory
   • BuildRoot - Location where the software will be installed. Note that this is automatically set up by rpmdev-newspec and should not be changed. Depracated and ignored in new versions of RPM
   • BuildRequires - packages and capabilities required to build the software. For example, software written in fortran might require the gfortran package in order to be built successfully, but may not require gfortran to be installed for use. A very basic set of build capabilities is always assumed (including bash, make, gcc, and ld)
   • Requires - packages and capabilities required to install and use the software. For example, software written in Python will require the Python interpreter, and web applications will require a web server
   •  %description - a detailed, multi-line description of the package
2.  %prep - commands to prepare the package for building. This might include operations such as untarring or unzipping the archive and applying any patch files
3.  %build - commands to build the package, such as compiling, linking, building game data, processing sound/video/font files, and so forth
4.  %install - commands to install the built files. These files will be installed into the buildroot rather than into the actual destination location. For example, files that will ultimately be installed into /usr/bin are installed into $RPM_BUILD_ROOT/usr/bin during the install process (usually written using macros as %{buildroot}/%{_bindir}). The installation is typically done by a make install DESTDIR=$RPM_BUILD_ROOT command, but if the software has no make install capability, this section may consist of a series of commands to create directories and copy files to the correct location. Everything installed in the buildroot must ultimately be included in the binary RPM, so any files that are not desired are deleted during the install phase of the build
5.  %check - commands to check/test the built files (optional, often not included). If the upstream software includes automated tests, they should be executed in this section
6.  %clean - commands to clean up the disk space - this section is deprecated and will not be used in new versions of RPM. The commands created by rpmdev-newspec are sufficient and should not be changed
7.  %files - list of files to be included in the package. Every file in the buildroot must be specified here so that it is included in the binary RPM. In addition, any documentation files in the original source archive that should be included, such as a README file or license text, must be identified with the %doc macro. Configuration files must be identified with the %config(replace) or %config(noreplace) macros
8.  %changelog - record of the package's change-history. Each new

Scriptlets

Short script segments which are executed when the RPM is installed or removed. Each script is placed in its own section, with an identifying macro:

•  %pre -- run before installation
•  %post -- run after installation
•  %preun -- run before uninstallation
•  %postun -- run after uninstallation

Note that during upgrade, the installation of the new package is considered to happen before the removal of the old package. Therefore, the order of execution of the scripts during an upgrade is:

•  %pre from the new package
•  %post from the new package
•  %preun from the old package
•  %postun from the old package

The first and only argument passed to these scripts is a number indicating the count of installed packages that have the same name as the current package, as it will be after the current operation is completed:

• for a fresh in install: 1 during %pre and %post
• for a final removal: 0 during %preun and %postun
• for an update: 2 during %pre and %post, and 1 during %preun and %postun

Scripts may use these values to alter their behaviour (for example, to preserve data or perform conversions during an update).

Triggers

Triggers are scripts that are executed when another, related RPM is installed or removed. The use of triggers should be avoided.

Macros

Macros are a type of text variable that get substituted into the spec file in place of the variable name. For example, if the macro foo is defined:

%foo 3

The this line:

Release: %{foo}

Is evaluated as:

Release: 3

Macros can be as short as null (nothing) or as long as several pages of text. Confusingly, they are used both as variables and as procedures or functions.

Common Procedure Macros

•  %setup - a macro used in the %configure section which performs the customary steps of unpacking the tarball (or zip file) for Source0 and then changing into the directory identified by %{name}-%{version}. For example, if the name of the package is foo and the version is 1.2, then the %setup macro will unpack that tarball and change to the directory foo-1.2. However, if the source archive is was not originally designed to unpack in this way, then the behaviour of %setup can be modified using options -- see the details on the Fedora wiki
•  %configure - a macro which executes a ./configure script.
•  %makeinstall - a macro which runs make install with appropriate arguments. This is deprecated and should not be used

Common Variable Macros

• Macros used to hold paths:
  •  %{buildroot} - equivalent to the RPM_BUILD_ROOT environment variable - contains the name of the directory into which files will be installed before packaging
  •  %{_bindir} - /usr/bin
  •  %{_datadir} - /usr/share
  •  %{_mandir} - /usr/share/man
• Macros containing flags passed to make and cc or gcc:
  •  %{_smp_flags} - passed to make to execute jobs in parallel. Usually defined in ~/.rpmmacros
  •  %{optflags} - options for the gcc compiler. Usually passed to make as CCOPTIONS: make CCOPTIONS="%{optflags} -c" ${_smp_flags}
• Macros containing information from the metadata section of the spec file:
  •  %{name}
  •  %{version}
  •  %{release}
  • ...etc...
• Macros used in the %files section:
  •  %defattr() - sets default file attributes for files in the binary RPM. Four attributes are placed in the parenthesis: permissions for files (or - to use the permissions already present on the files), owner of files and directories, group of files and directories, permissions for directories (or - to use the permissions already present on the files). Example: <code>%defattr(-,root,root,-) will keep file and directory permissions, and will make root the owner and group for all packaged files
  •  %attr() - like %defattr but affects only files listed on the same line
  •  %doc - all files listed on this line will be treated as documentation. These files are not typically located in the buildroot, but are found in the source archive (for example: README.txt, INSTALL, COPYING)
  •  %config(replace) and %config(noreplace) - marks files as config files. Config files marked as replace are installed in place of the previous config file when the software is upgraded, after renaming the previous config file name.rpmold; those marked as noreplace are saved as name.rpmnew - therefore, config files which are compatible with the previous version of the software should be marked as noreplace, while config files which are incompatible with the previous version of the software should be marked as replace