Building RPMs using Mock's SCM integration

Building a single RPM once is a relatively simple task, which is accomplished by tweaking the spec file and running it through rpmbuild on the local system. However, when more than one or two people are involved and several RPMs for several distributions are being maintained over a long period of time, reproducibility and change tracking become essential. A new feature in Mock, which builds RPMs from source, will make it easier for developers and projects to handle this task.

Koji offers a centralized build system for distributions like Fedora with hundreds of developers and a dedicated infrastructure team. Unfortunately, setting up Koji is not the most straightforward task. Few will enjoy investigating miscommunications between Koji components when building an RPM fails, for example, or how to adjust repository settings in a database instead of a simple yum-format configuration file. In some cases Koji's centralized nature is also a limitation because using it might require setting up a VPN connection to an organization's network.

Mock is the tool used by Koji to create chroots and build RPMs in them. Up until recently, Mock, which runs on the local system, has required source RPMs when used directly. This is not really optimal since building source RPMs requires extra steps. It is also worth remembering that the RPM version of RHEL 4/5 is unable to handle source RPMs created with the default options on RHEL 6 or recent Fedoras due to RPM package format changes.

The recent release of Mock 1.1.10 introduces an interesting feature to seamlessly integrate RPM building with CVS/Git/SVN workflow. After initial Mock installation and configuration (i.e., just adding user(s) to the mock group) all that's needed is to define the default source code management (SCM) method and its checkout command in Mock's site-defaults.cfg main configuration file. After that Mock can build RPMs directly from the SCM repository provided that a spec file suitable for rpmbuild is found inside the repository. Mock first builds the source RPM in a selected chroot and then the binary RPMs from it in the same chroot.

Building an RPM directly from the default SCM in a Mock chroot is as easy as:

    mock -r fedora-14-i386 --scm-enable --scm-option package=testpkg -v

In this example first the target (-r fedora-14-i386) is specified, then the SCM integration is enabled (--scm-enable) and the actual package to be build is set (--scm-option package=testpkg). Also, a modest level of tracing is enabled (-v). Otherwise defaults from the Mock configuration file are used, including the default SCM method (one of CVS/Git/SVN) and the location of the SCM repository.

This SCM integration allows two possibilities for setting up repositories: the repository may contain all the source and configuration files needed for a package (the tar ball needed during the build process will be generated on-the-fly) or the repository may contain only the spec file, possible patches, and local configuration files, then the tar package can be fetched from an NFS mounted directory for example. Then Mock running on a 64-bit RHEL 6 system, for instance, can be used to build RPMs from an SCM for 32/64-bit RHEL 4/5/6, Fedoras, and other RPM-based distributions. In many cases a spec file doesn't need any extra directives for different distributions but, if needed, distribution or version specific if/else definitions can be used to allow using the same spec file for all targets. As long as the package repositories for targets are publicly available, no access to the organization's network is needed when building.

Using Mock's SCM integration capabilities allow organizations' package maintainers to combine the easiness of plain rpmbuild with build reproducibility and change tracking offered by Mock and SCMs, but without the overhead of Koji. Trivial configuration, being able to trace the build process locally if needed, and using the build system while roaming are also noteworthy features. In the future, integrating all this into higher level tools like Emacs or Eclipse would open interesting possibilities for developers: generating RPMs for several targeted distributions directly from an SCM in a reproducible manner with a single click on the GUI.