Package management is one the key areas in the world of GNU/Linux system administration. Not only for system administrators but also for normal linux users it is an inevitable part that they need to be aware of in their day to day job. Even though hundreds of linux distros exist around us, number package management systems are very limited (in numbers). dpkg used by Debian with .deb format, RPM created by Red Hat with .rpm format, pacman used in Arch linux, portage by Gentoo etc are some of the popular ones among them. Considering the most used RPM and DEB packages, they both have proven to work flawless. It’s just a matter of personal taste to select one from the other. Here we discuss on how to build RPM based packages for different distros which makes you of .rpm to install softwares. Here is how a rpm package would like:
where <name> is samba, <version> is 4.2.3, <release> is 1.fc23 and <architecture> is x86_64. <release> part is often a combination of a positive integer with a distribution tag appended at its end. See here for more details.
For example Fedora, RHEL, OpenSUSE, Mandriva etc uses RPM, which is a recursive acronym for RPM Packae Manager, for managing their packages. Also several front-ends to RPM have been developed to ease the process of obtaining and installing RPMs from repositories and to help in resolving their dependencies. YUM, DNF, Zypper, up2date, urpmi etc are examples for these front end utilities. Following are some RPM related terms that you will need to understand as we move forward…
# spec file: This is the heart of rpm building process which includes details on how a package is configured, what patches are applied, what files will be installed and where they’ll be installed, and what needs to be done before and after a package is installed.
# SRPM: It is the source package which contains everything needed to recreate not only the programs and associated files that are contained in the binary package file, but the binary and source package files themselves. We can directly install SRPMS without converting it into rpms.
What is Mock and how do I set it up?
Quoting the words from fedora wiki, Mock is a tool for building packages for different architectures and different Fedora or RHEL versions than the build host has under chroots and builds packages in them. To know more about chroots, see my previous article here. To use mock, first install the mock package and add the required user to group named mock as follows
# usermod -a -G mock [username>
Various configuration files for mock are located under /etc/mock. By default, builds are done in /var/lib/mock and with newer versions (>= 0.8.0) you change this via specific options.
How to create packages from srpm using Mock?
The content of a mocked chroot is specified by the configuration specified with the -r option. The default configuration is specified by /etc/mock/default.cfg which will point to the host systems configuration i.e, if you are building on a fedora 23 x86_64 host then /etc/mock/default.cfg will be a symlink to /etc/mock/fedora-23-x86_64.cfg. You change this default.cfg to point towards any other configuration. For example, if you always build packages for EPEL 7 x86_64 then do the following:
# cd /etc/mock
# ln -s –force epel-7-x86_64.cfg default.cfg
Download the srpm for a particular package from web and change to the directory where it belongs. Now you can start mock with:
# mock -r <configfile> –rebuild package-1.2-3.src.rpm
where <configfile> is the name of configuration from /etc/mock without .cfg. If you have set default configuration correctly as mentioned above, then you just need to run mock with srpm name as follows:
# mock package-1.2-3.src.rpm
as –rebuild is the default option. You can check the result under /var/lib/mock/<configuration>/result.
Don’t have srpms? Create on your own with mock
If you can’t find srpm, then use source tarball and spec file provided by the project to build srpms. In order to do this we have to download the tarball of a specific version of software along with its spec file. As before change to the directory where these two were downloaded. Run the following command:
# mock -r epel-7-x86_64 –buildsrpm –spec <specfile> –sources .
Note 1: Sometimes spec file expects tarball to be in a partcular compression format like .xz, .gz etc. You may need to convert as required.
Note 2: Also spec file will mention about some patches to be applied while building the srpms. So make sure that you have all the input files like default software configurations, extra patches, READMEs etc downloaded to the same directory.
How to build from SCM systems using mock?
What happens if you fail to find srpms or tarballs? Do not worry. Mock has yet another plugin which provides integration to SCM systems like GIT, SVN, CVS etc. Install mock-scm package inorder to make use of this feature with mock. You can follow either of the following two ways to build binary packages. Example used here is to build git-lfs packages for fedora-23-x86_64.
 via config file
Copy /etc/mock/fedora-23-x86_64.cfg to present working directory.
# cp /etc/mock/fedora-23-x86_64.cfg ./git-lfs-fedora-23-x86_64.cfg
# vim git-lfs-fedora-23-x86_64.cfg
Then add the following lines to it
config_opts[‘scm’] = True
config_opts[‘scm_opts’][‘method’] = ‘git’
config_opts[‘scm_opts’][‘git_get’] = ‘git clone https://github.com/github/git-lfs.git‘
config_opts[‘scm_opts’][‘spec’] = ‘rpm/SPECS/git-lfs.spec’
config_opts[‘scm_opts’][‘write_tar’] = True
config_opts[‘scm_opts’][‘package’] = ‘git-lfs’
config_opts[‘scm_opts’][‘branch’] = ‘v1.1.0’
# mock -r ./git-lfs-fedora-23-x86_64.cfg
and that’s it.
 via command line
Mock scm gives you an option to specify options via command-line too. Specify the scm config options as follows:
# mock -r fedora-23-x86_64 –scm-enable –scm-option method=git –scm-option package=git-lfs –scm-option git_get=set –scm-option spec=rpm/SPECS/git-lfs.spec –scm-option branch=v1.1.0 –scm-option write_tar=True –scm-option git_get=’git clone https://github.com/github/git-lfs.git‘
You can find your srpms and rpms under /var/lib/mock/fedora-23-x86_64/result. Even though first option is valid, I would always recommend the second option as I have tried myself and was able to build it successfully.
That’s all for now. Try hands-on with mock by building your test packages and you will find it amazing!