Oh Package of Packages

Let's talk about the RedHat Package Manager, now known as the RPM Package Manager, and while we're at it... let's talk about packages under Linux in general. Packages at a basic level are modular. They mostly play a part of a bigger picture. Think of them as building blocks. A good example would be a simple calculator program. The calculator itself would have an umbrella package, but this package would require certain packages to be installed before it would install itself. These required... or dependent packages might include a graphical API, a math package and a fractoral package. The great news about this method of package control is that if another program was introduced into the system, say a loan calculator, it would be able to re-use the graphical, math and fractoral packages... saving system resources.

This means that Linux packages are generally smaller in size compared to their non-Linux counterparts... because these core functions do not have to be built in. Windows packages perform some re-use when it comes to .dll files, but this practice is limited... even though a loan calculator and a calculator may use 50% of the same components, they will just be installed for the second time. This process of dependencies is well known in the Linux world.

Here though, we must pause and identify a difference between software installation in Linux. There are generally two ways of software installation in Linux and this can confuse users.

Firstly, there is the RPM practice of installation... the easiest. These RPMs are installed by applications such as YUM or apt, which are online repositories of RPMs. Why wouldn't everyone use RPMs then? For one simple reason... RPMs are platform dependent. When I unveiled my loan calculator (ex), I would need to build several RPMs, for Fedora Core 4, Fedora Code 5, Fedora Core 6, SuSE 10.0, SuSE 10.1, SuSE 10.2 ... additionally I would need RPMs for different architectures (32bit, 64bit).

I would then submit those RPMs to the correct repository and the next time a client requested my program the repository would deliver the correct version. Sometimes, RPMs can be used on more than one platform/architecture, but this can result in unexpected behavior and is unusual in complicated software.

As you can see... a good deal of atypical software is therefore published as source.... but what is this strange term? In recent decades our own source has been brought into question... giving the term an almost higher-power meaning... in the Linux world the meaning differs only slightly. Welcome to the exciting world of open source programming.

The term "building from source" can seem a little daunting at first... I know that it was to me. Unlike a simple GUI based point and click installation, building from source can be a tricky CLI (command line interface) task. Building from source has a huge advantage though, the same piece of software can be used (for the most part) on any distribution and architecture... it is universal.

Take a look at the graphic below; the source code (left) talks to the headers and build executables (center), they then build that source code around the system distribution and architecture and it is then installed on the system to be executed (right).


Pretty straightforward? Well there are some drawbacks to this method. Firstly, the headers and build executables have to be installed, then the dependencies must be installed before any compilation can begin. Unlike RPMs, these dependencies are not automatically installed. In some cases the user is informed of the missing dependency... in some cases not. In addition, development packages are sometimes required that would not otherwise be required if installing from an RPM. These development packages are critical to the build process... during a complicated install you may have tens of packages that you would not have otherwise needed installed!