Create an account

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Fedora - How RPM packages are made: the spec file

How RPM packages are made: the spec file

In the previous article on RPM package building, you saw that source RPMS include the source code of the software, along with a “spec” file. This post digs into the spec file, which contains instructions on how to build the RPM. Again, this article uses fpaste as an example.

Understanding the source code

Before you can start writing a spec file, you need to have some idea of the software that you’re looking to package. Here, you’re looking at fpaste, a very simple piece of software. It is written in Python, and is a one file script. When a new version is released, it’s provided here on Pagure:

The current version, as the archive shows, is Download it so you can see what’s in the archive:

$ wget
$ tar -tvf fpaste-
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-
-rw-rw-r-- root/root 25 2018-07-25 02:58 fpaste-
-rw-rw-r-- root/root 3672 2018-07-25 02:58 fpaste-
-rw-rw-r-- root/root 35147 2018-07-25 02:58 fpaste-
-rw-rw-r-- root/root 444 2018-07-25 02:58 fpaste-
-rw-rw-r-- root/root 1656 2018-07-25 02:58 fpaste-
-rw-rw-r-- root/root 658 2018-07-25 02:58 fpaste-
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-
-rw-rw-r-- root/root 3867 2018-07-25 02:58 fpaste-
-rwxrwxr-x root/root 24884 2018-07-25 02:58 fpaste-
lrwxrwxrwx root/root 0 2018-07-25 02:58 fpaste- -> fpaste

The files you want to install are:

  • which should go be installed to /usr/bin/.
  • docs/man/en/fpaste.1: the manual, which should go to /usr/share/man/man1/.
  • COPYING: the license text, which should go to /usr/share/license/fpaste/.
  • README.rst, TODO: miscellaneous documentation that goes to /usr/share/doc/fpaste.

Where these files are installed depends on the Filesystem Hierarchy Standard. To learn more about it, you can either read here: or look at the man page on your Fedora system:

$ man hier

Part 1: What are we building?

Now that we know what files we have in the source, and where they are to go, let’s look at the spec file. You can see the full file here:

Here is the first part of the spec file:

Name: fpaste
Release: 3%{?dist}
Summary: A simple tool for pasting info onto sticky notes instances
BuildArch: noarch
License: GPLv3+
Source0: Requires: python3 %description
It is often useful to be able to easily paste text to the Fedora
Pastebin at and this simple script
will do that and return the resulting URL so that people may
examine the output. This can hopefully help folks who are for
some reason stuck without X, working remotely, or any other
reason they may be unable to paste something into the pastebin

Name, Version, and so on are called tags, and are defined in RPM. This means you can’t just make up tags. RPM won’t understand them if you do! The tags to keep an eye out for are:

  • Source0: tells RPM where the source archive for this software is located.
  • Requires: lists run-time dependencies for the software. RPM can automatically detect quite a few of these, but in some cases they must be mentioned manually. A run-time dependency is a capability (often a package) that must be on the system for this package to function. This is how dnf detects whether it needs to pull in other packages when you install this package.
  • BuildRequires: lists the build-time dependencies for this software. These must generally be determined manually and added to the spec file.
  • BuildArch: the computer architectures that this software is being built for. If this tag is left out, the software will be built for all supported architectures. The value noarch means the software is architecture independent (like fpaste, which is written purely in Python).

This section provides general information about fpaste: what it is, which version is being made into an RPM, its license, and so on. If you have fpaste installed, and look at its metadata, you can see this information included in the RPM:

$ sudo dnf install fpaste
$ rpm -qi fpaste
Name : fpaste
Version :
Release : 2.fc30

RPM adds a few extra tags automatically that represent things that it knows.

At this point, we have the general information about the software that we’re building an RPM for. Next, we start telling RPM what to do.

Part 2: Preparing for the build

The next part of the spec is the preparation section, denoted by %prep:


For fpaste, the only command here is %autosetup. This simply extracts the tar archive into a new folder and keeps it ready for the next section where we build it. You can do more here, like apply patches, modify files for different purposes, and so on. If you did look at the contents of the source rpm for Python, you would have seen lots of patches there. These are all applied in this section.

Typically anything in a spec file with the % prefix is a macro or label that RPM interprets in a special way. Often these will appear with curly braces, such as %{example}.

Part 3: Building the software

The next section is where the software is built, denoted by “%build”. Now, since fpaste is a simple, pure Python script, it doesn’t need to be built. So, here we get:

#nothing required

Generally, though, you’d have build commands here, like:

configure; make

The build section is often the hardest section of the spec, because this is where the software is being built from source. This requires you to know what build system the tool is using, which could be one of many: Autotools, CMake, Meson, Setuptools (for Python) and so on. Each has its own commands and style. You need to know these well enough to get the software to build correctly.

Part 4: Installing the files

Once the software is built, it needs to be installed in the %install section:

mkdir -p %{buildroot}%{_bindir}
make install BINDIR=%{buildroot}%{_bindir} MANDIR=%{buildroot}%{_mandir}

RPM doesn’t tinker with your system files when building RPMs. It’s far too risky to add, remove, or modify files to a working installation. What if something breaks? So, instead RPM creates an artificial file system and works there. This is referred to as the buildroot. So, here in the buildroot, we create /usr/bin, represented by the macro %{_bindir}, and then install the files to it using the provided Makefile.

At this point, we have a built version of fpaste installed in our artificial buildroot.

Part 5: Listing all files to be included in the RPM

The last section of the spec file is the files section, %files. This is where we tell RPM what files to include in the archive it creates from this spec file. The fpaste file section is quite simple:

%doc README.rst TODO
%license COPYING

Notice how, here, we do not specify the buildroot. All of these paths are relative to it. The %doc and %license commands simply do a little more—they create the required folders and remember that these files must go there.

RPM is quite smart. If you’ve installed files in the %install section, but not listed them, it’ll tell you this, for example.

Part 6: Document all changes in the change log

Fedora is a community based project. Lots of contributors maintain and co-maintain packages. So it is imperative that there’s no confusion about what changes have been made to a package. To ensure this, the spec file contains the last section, the Changelog, %changelog:

* Thu Jul 25 2019 Fedora Release Engineering -
- Rebuilt for * Thu Jan 31 2019 Fedora Release Engineering -
- Rebuilt for * Tue Jul 24 2018 Ankur Sinha -
- Update to * Fri Jul 13 2018 Fedora Release Engineering -
- Rebuilt for * Wed Feb 07 2018 Fedora Release Engineering -
- Rebuilt for * Sun Sep 10 2017 Vasiliy N. Glazov -
- Cleanup spec * Fri Sep 08 2017 Ankur Sinha -
- Update to latest release
- fixes rhbz 1489605

There must be a changelog entry for every change to the spec file. As you see here, while I’ve updated the spec as the maintainer, others have too. Having the changes documented clearly helps everyone know what the current status of the spec is. For all packages installed on your system, you can use rpm to see their changelogs:

$ rpm -q --changelog fpaste

Building the RPM

Now we are ready to build the RPM. If you want to follow along and run the commands below, please ensure that you followed the steps in the previous post to set your system up for building RPMs.

We place the fpaste spec file in ~/rpmbuild/SPECS, the source code archive in ~/rpmbuild/SOURCES/ and can now create the source RPM:

$ cd ~/rpmbuild/SPECS
$ wget $ cd ~/rpmbuild/SOURCES
$ wget $ cd ~/rpmbuild/SOURCES
$ rpmbuild -bs fpaste.spec
Wrote: /home/asinha/rpmbuild/SRPMS/fpaste-

Let’s have a look at the results:

$ ls ~/rpmbuild/SRPMS/fpaste*
/home/asinha/rpmbuild/SRPMS/fpaste- $ rpm -qpl ~/rpmbuild/SRPMS/fpaste-

There we are — the source rpm has been built. Let’s build both the source and binary rpm together:

$ cd ~/rpmbuild/SPECS
$ rpmbuild -ba fpaste.spec

RPM will show you the complete build output, with details on what it is doing in each section that we saw before. This “build log” is extremely important. When builds do not go as expected, we packagers spend lots of time going through them, tracing the complete build path to see what went wrong.

That’s it really! Your ready-to-install RPMs are where they should be:

$ ls ~/rpmbuild/RPMS/noarch/


We’ve covered the basics of how RPMs are built from a spec file. This is by no means an exhaustive document. In fact, it isn’t documentation at all, really. It only tries to explain how things work under the hood. Here’s a short recap:

  • RPMs are of two types: source and binary.
  • Binary RPMs contain the files to be installed to use the software.
  • Source RPMs contain the information needed to build the binary RPMs: the complete source code, and the instructions on how to build the RPM in the spec file.
  • The spec file has various sections, each with its own purpose.

Here, we’ve built RPMs locally, on our Fedora installations. While this is the basic process, the RPMs we get from repositories are built on dedicated servers with strict configurations and methods to ensure correctness and security. This Fedora packaging pipeline will be discussed in a future post.

Would you like to get started with building packages, and help the Fedora community maintain the massive amount of software we provide? You can start here by joining the package collection maintainers.

For any queries, post to the Fedora developers mailing list—we’re always happy to help!


Here are some useful references to building RPMs:

Possibly Related Threads…
Thread Author Replies Views Last Post
  Fedora - Fedora pastebin and fpaste updates xSicKxBot 0 2 11-16-2019, 12:09 AM
Last Post: xSicKxBot
  Fedora - Edit images on Fedora easily with GIMP xSicKxBot 0 7 11-14-2019, 02:43 AM
Last Post: xSicKxBot
  Fedora - Understanding “disk space math” xSicKxBot 0 11 11-12-2019, 01:43 AM
Last Post: xSicKxBot
  Fedora - Managing software and services with Cockpit xSicKxBot 0 15 11-09-2019, 04:28 AM
Last Post: xSicKxBot
  Fedora - Tuning your bash or zsh shell on Fedora Workstation and Silverblue xSicKxBot 0 22 11-07-2019, 10:43 PM
Last Post: xSicKxBot
  Fedora - Cloning a MAC address to bypass a captive portal xSicKxBot 0 25 11-04-2019, 11:25 PM
Last Post: xSicKxBot
  Fedora - Fedora 31 is officially here! xSicKxBot 0 25 11-02-2019, 12:27 AM
Last Post: xSicKxBot
  Fedora - Firefox tips for Fedora 31 xSicKxBot 0 34 11-01-2019, 12:09 AM
Last Post: xSicKxBot
  Fedora - Upgrading Fedora 30 to Fedora 31 xSicKxBot 0 25 10-30-2019, 11:38 PM
Last Post: xSicKxBot
  Fedora - What’s new in Fedora 31 Workstation xSicKxBot 0 25 10-29-2019, 08:50 PM
Last Post: xSicKxBot

Forum Jump:

Users browsing this thread:
1 Guest(s)

Copyright © 2012-2019