Building and Modifying Source RPMs
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Building and Modifying Source RPMs
The tool used to rebuild RPM packages is the same command-line tool used to manage them: rpm. This article gives an overview of the build process, starting with a little bit of history to explain why the packaging system works the way it does.
There are many good reasons for rebuilding RPM packages. You may not be able to find a binary RPM that works well with your distribution. Source RPMs (also called SRPMs) are often much more adaptable to different distributions and architectures than binary RPMs. You might also want to change the options that the software was compiled with or even change the software itself. Finally, using SRPMs can help protect you from malicious packages because you can look at all the source code.
Philosophy of RPM
Before diving into the details of rebuilding packages, it helps to learn some of the philosophy behind the package manager as well as something about the development methods commonly used with open source software.
In the Unix and Unix-like world, open source software has historically been distributed in the form of TAR files that contain the source code necessary to build the software on your machine. Sometimes these bundles of files include readily executable binaries. Often, however, you are expected to compile the software and install it yourself using the source files in the TAR. Because there are various versions of Unix-like operating systems from different vendors, the software has to be written so that it can compile for many different OS versions and platforms (processors).
RPM is derived from this heritage of starting with source code from TAR files and, from that, producing working software. What differentiates RPM from other packaging systems is that it tries to automate the steps required to go from the author's original source code to a very easy-to-install package. This was done to make it easier to maintain a distribution of Linux, which might include hundreds or even thousands of packages. Therefore, although the automation provided by the package-building system is essential to a distribution vendor, it also provides some important benefits to the end users of the software—they can use the same automated steps to rebuild the software on their own machines.
Working with Original Sources
One overriding philosophy of RPM is that it can be used to rebuild—from original sources obtained from the Internet—software that runs effectively.
Getting software to run on a particular machine or version of OS often requires that changes be made to the software. To help others who might want to use the software on similar machines, a developer makes changes and then submits the modifications back to the original author of the software in the form of patches. The original author often includes the changes in the next release of the software. Sometimes, however, the author doesn't have the time or inclination to include new patches; therefore, subsequent releases of the software need to have the same set of patches applied to get them to compile again on the target platform.
The philosophy behind RPM is to provide clean sources plus patches. "Clean sources" means that an SRPM is expected to be shipped with an exact copy of the sources that the original author provided. Because these sources may not meet the needs of the packager's audience, the packager can also include patches to be applied to the clean sources. Patches are short files that instruct a tool called patch how to change one source tree into another. For instance, the patch may include instructions to delete several lines of code, add a new file, and modify the documentation. Any text file can be manipulated using patch, and RPM also provides mechanisms for distributing new versions of binaries if these are required.
There are many advantages to providing the clean sources plus patches rather than just providing the patched sources. By providing clean sources, the user can more easily verify that the program received is what it claims to be. It also makes it much easier to rebuild the package when a new version of the software becomes available.