Source Code and RPM Packages – Understanding the Difference and Choosing your Route

Often times a system administrator faces the task of installing a utility or application. This article is intended to address the common questions system administrators have regarding the differences between installing services and applications from source code and package management perspectives in a Linux environment.  For the purpose of this article we will be discussing a Red Hat Enterprise Linux environment.

For those unfamiliar with the fundamental differences, the following definitions may assist -

Source Code:  Often present in downloadable form with a .bz2 or .gz extension, these compressed archives contain the header and library files that have yet to be compiled.  Once extracted from the compressed archive, these files can be modified to your liking, and then compiled on the system they are intended to be used.  The compiled output results in a binary (executable).

RPM:  A system of package management which is often present in downloadable form with an .rpm extension, these packages contain the already compiled files for your particular system.  RPM packages are put together and designed to extract all libraries, configuration files and binaries into their intended locations.

Lets now take a look at the pros/cons of compiling from source vs. using a precompiled package.

RPM (Package Management)

Source code does require a level of understanding as to the structure of compile time antics.  Often times a configure script may error out due to missing libraries, however, it will usually go so far as to tell you where you may obtain the necessary files to complete the build.

The biggest benefit of compiling from source is the ability to pick and choose how your program is built.  In other words, you as the administrator get to decide which modules and add-ons will be built into the program, allowing you to build a lightweight service, or a bloated ‘everything' installation.

PHP is a great example of the beauty of compiling your own service from source.  A typical packaged version of PHP will contain a significant array of compiled in functions, most of which you may never find a use for.  By compiling PHP from source, you have access to dozens of different compile time modules giving you the flexibility of choice.  You may find a requirement for function XYZ, which a prepackaged version of PHP did not support - in a source scenario you can quickly recompile PHP and add-in the necessary module.

A common misconception of using package management systems results from the nomenclature methods used by Linux distributors such as Red Hat.  For example, the current PHP package for Red Hat Enterprise Linux is 4.3.2.  The misconception is that this package is several versions off of the current 4.x release at www.php.net (4.3.10) and therefore is an insecure and outdated solution.

If you take a look at the actual package name of the current red hat release, it will list 4.3.2-19, which indicates that there have been 19 different significant updates made by the Red Hat developers to this PHP package.  These updates will have included any and often times more updates and changes that have been made since the latest official source release.

In the world of system administration, both source code and package management have a home.  Source code is a wonderful solution in public service environments, where public services are exposed to internet traffic on a routine basis.  They allow for a more scrutinized and massaged implementation of the service in question.  On the other hand, package management allows for a system administrator to manage thousands of different utilities and services, with very little effort.

I find a combination of both technologies to be the best method of administering a linux server.  Let the package management solution handle the hundreds of various utilities and programs that make up your system, and compile your core utilities and programs such as Apache, MySQL/PHP and BIND from source.

If you have any questions or concerns regarding this article, please do not hesitate to contact me directly.