Working with Source RPMs | Packagecloud Blog (2024)

What are source RPMs?

A package is a collection of binaries, scripts, and associated data that is installed by your package manager.

Packages are typically generated from source code and a set of a metadata written by the package maintainer. Occasionally, the source may by patched by the package maintainer at build time.

A source RPM captures the source code and patches as they were at RPM build time.

On RPM-based systems (CentOS, Red Hat Enterprise Linux, Oracle Linux, and many more) source RPMs are RPM files that contain a tarball of source code, patches, auxiliary files that are used during the build process, and a .spec file for generating the RPM.

Why are source RPMs useful?

Source RPMs are extremely useful for:

• Regenerating binary packages
• Debugging issues with applications and libraries
• Modifying existing applications to add additional logging
• Confirming whether or not a particular security fix has been applied to the source

Westronglyrecommend that people and organizations running applications in production on RPM-based systems become familiar with RPM source packages so that when a bug appears, system operators and developers will have the tools to quickly and easily obtain the source and debug the issue.

Working with source RPMs

If you intend to rebuild or modify a source RPM, it is strongly recommended that you install theyum-utilsandrpm-buildpackages which contains many useful tools for working withyumand RPMs:

$ sudo yum install yum-utils rpm-build

Getting Source RPMs

Getting the source for an RPM package is not as straight-forward as obtaining source packages for other systems.

Start by usingyumdownloaderwhich is part of theyum-utilspackage. This program will download the source RPM for the named package.

For example, to get the source RPM forredisrun:

$ yumdownloader --source redis

This will download theredissource RPM file in the current working directory.

Next, you must install the source RPM. When a source RPM is installed, the source tarballs, patches, and auxilliary files will be installed under a top level directory. This directory is calledtopdir. You can get the current value oftopdirby checking the output ofrpm --showrc | grep topdir. On many systems, the default value isrpmbuildin the current user’s home directory.

You can set your owntopdirby creating a file named.rpmmacrosin your home directory like this:

%_topdir %(echo $HOME)/my-rpm-build-dir

This sample.rpmmacrosfile will cause source RPMs installed by you to be written tomy-rpm-build-dirin your home directory.

You can now install the source RPM:

$ rpm -ivh ./redis-2.8.19-1.el7.src.rpm

This will write the source tarballs, patches, and other files to theSOURCESdirectory under your specifiedtopdir. The RPM spec file will be written toSPECS.

Install Source RPM build dependencies

You should now install the source RPM’s build dependencies by usingyum-builddep:

$ sudo yum-builddep redis

Preparing the source

Now, that you’ve installed the source RPM and build dependencies, you can prepare the source so that all patches are applied. This brings the source into the state it was in when the RPM was built.

Begin by switching to theSPECSdirectory under yourtopdir:

$ cd rpmbuild/SPECS

Next, prepare the source using therpmbuildprogram, passing the-bpflag, and specifying the spec filename:

$ rpmbuild -bp redis.spec

Now, you can examine the source. It is found in theBUILDdirectory undertopdir:

$ ls ~/rpmbuild/BUILDredis-2.8.19

Now, you can look through the source code for Redis precisely as it was when Redis was compiled and put into the package that you have installed on your system.

Modifying the source and applying patches

Patches are applied to source code during the RPM build process by listing patches in the RPM spec file, and then applied during the build process.

For example, inredis.spec, a patch is specified like this:

Patch0001: 0001-redis-2.8.18-redis-conf.patch

The actual application happens before the%buildstep:

%patch0001 -p1

Updating the RPM package version number

Updating the RPM package version number is done by modifying theReleasefield found in the RPM spec file.

Typically, theVersionfield is set to the version of the source itself whereas theReleasefield is incremented for each RPM packaging related change.

Rebuilding the package

Now, you are ready to rebuild the RPM package!

You can do this by running the following command in theSPECSdirectory:

$ rpmbuild -ba redis.spec

This will build and write a source RPM and a binary RPM in theSRPMSandRPMSdirectories, respectively.

Upload Source RPMs topackagecloud.io

You can now upload your source RPMs topackagecloud.

You simply push the source RPM just as you would any other RPM with thepackage_cloudCLI.

For example, to upload a source RPM to CentOS 7:

$ package_cloud push user/repo/el/7 redis-2.8.19-1.el7.src.rpmLooking for repository at user/repo... success!Pushing redis-2.8.19-1.el7.src.rpm... success!

The packagecloud command line client uses thepackage create APIto upload the source RPM file.

Conclusion

The RPM package toolchain enables users to quickly and easily recreate the source tree for a package as it was at build time. This is incredibly useful for debugging strange application behavior and for adding additional logging output to applications that aren’t telling you what you need to know when they run.

Becoming familiar with the workflow of obtaining source code via the package manager is essential for debugging and administering infrastructure of any size.