Building RPM packages with mock

May 11, 2015 • packagecloud

TL;DR

mock is a tool for building RPM packages. You can use mock to build packages for many different versions of CentOS/Red Hat and Fedora.

The main advantage of using mock to build RPMs instead of rpmbuild is that mock builds RPMs in a cleanroom environment. mock does this by creating a chroot and performing the RPM build in the chroot.

This article explains how to setup mock and how to build RPMs using it.

Create an RPM repository in less than 10 seconds, free.

Setup

Install EPEL

To install mock, you must first install the Extra Packages for Enterprise Linux (EPEL) repository on your system.

You can install EPEL on CentOS by running the following commands:

$ sudo yum install epel-release

You can learn more about EPEL by checking the wiki page.

Install mock

Once you’ve installed EPEL, you can install mock:

$ sudo yum install mock

User permissions for mock

Any user who will run mock must be added to the mock group. You can do this by running the command usermod.

For example, the user joe can be added to the mock group like this:

$ sudo usermod -a -G mock joe

Prepare your build

Once you’ve installed mock and put the user in the mock group, you must next prepare the source RPM to be built.

mock builds binary RPMs from source RPMs. So, before you can do your build you must either generate a source RPM yourself or download the source RPM for the package you’d like to build.

To generate your own source RPM, you will need to write your own Spec file.

If you are rebuilding an existing package, you must download the source RPM.

If you are writing your own Spec file, you will need to build an SRPM from the Spec file by using rpmbuild:

$ rpmbuild -bs mypackage.spec

You learn more about dealing with source RPMs by reading our previous blog post about source RPMs.

Building an RPM with mock

mock config files

Now that’ve you’ve either downloaded or built the source RPM, you can use mock to generate the binary RPM.

When running mock, you must specify a configuration file to use when generating the chroot and performing the build. The mock configuration files specify the CPU architecture and Linux version of the chroot.

mock configuration files live in /etc/mock/, for example:

[joe@centos6 ~]$ ls -alhrt /etc/mock/epel-*
-rw-r--r-- 1 root mock 1.7K Feb 13 02:58 /etc/mock/epel-7-x86_64.cfg
-rw-r--r-- 1 root mock 1.5K Feb 13 02:58 /etc/mock/epel-6-x86_64.cfg
-rw-r--r-- 1 root mock 1.3K Feb 13 02:58 /etc/mock/epel-6-ppc64.cfg
-rw-r--r-- 1 root mock 1.5K Feb 13 02:58 /etc/mock/epel-6-i386.cfg
-rw-r--r-- 1 root mock 1.6K Feb 13 02:58 /etc/mock/epel-5-x86_64.cfg
-rw-r--r-- 1 root mock 1.6K Feb 13 02:58 /etc/mock/epel-5-ppc.cfg
-rw-r--r-- 1 root mock 1.6K Feb 13 02:58 /etc/mock/epel-5-i386.cfg

As you can see above, there are configuration files for building RPMs on x86_64, PowerPC, and i386 for Red Hat and CentOS 5, 6 and 7.

The examples in the following sections will use the CentOS / Red Hat 7 x86_64 config file, but any other config file can be used in its place.

Initializing and deleting the mock chroot

You can initialize the mock chroot before performing the first build. This will reduce the build time when you do perform the build later.

mock will re-use the base chroot after it has been initialized. This helps to reduce build time.

In order to initialize the chroot for epel-7-x86_64 run the command:

$ mock -r epel-7-x86_64 --init

Similarly, you can delete the chroot by running the command:

$ mock -r epel-7-x86_64 --clean

Performing the build

You can perform the build by running:

$ mock -r epel-7-x86_64 rebuild package-1.1-1.src.rpm

The build may take some time if you have not previously initialized a CentOS / Red Hat 7 chroot.

Once the build has concluded, you will find results and logs in /var/lib/mock/epel-7-x86_64/result. You can change the directory where the RPMs are written by passing the --resultdir option to mock.

Conclusion

Using mock when building RPMs allows you to build RPMs for multiple architectures, ensures that the resulting RPMs contain no artifacts from previous builds, and provides a simple interface for reproducible builds.

Users who currently build binary RPMs with just rpmbuild are strongly encouraged to consider how their build process might be modified to support the use of mock.

Never miss an update!

Subscribe to our RSS feed