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.
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.
