22 Apr RPM is Good Thing ™
My first exposure to Linux was the Slackware distribution back in the early 1990’s. I don’t remember exactly how it was installed, but all I remember there were a bunch of binary and source files on a CD. By today’s standard, the number of packages was quite small. I remember that the general advice for upgrading was to save all your data and reinstall the new version. For this reason, I never installed another Slackware distribution, although I was very happy with my first version of Linux!
I then decided to try this “Red Hat” version because they had this management “thing” called Red Hat Package Manager or RPM. It definitely made life easier. I could upgrade packages and even whole distributions without having to reinstall everything. I’m convinced RPM (and dpkg from Debian) accelerated the growth of Linux by helping to manage all the various component software packages.
One of the key features of RPM was the inclusion of dependencies. Often considered a pain, package dependency ensured that everything would work together — there would be no library incompatibles like the DLL problems found with Windows. This “feature” actually allowed entire working distributions to be created and maintained. That is, libraries and languages could be built against a consistent environment that then was used to build applications. In the end everything worked even when adding or updating packages. In a way, RPM dependency trees create a “non-portability” between distributions because an RPM from one major version is not guaranteed not to work with a newer version. As a user, you could always download the source code and build packages, but you gave up the RPM management aspects that make life easier (more on that in moment).
As Linux distributions grew in breath and depth, so did the dependencies between packages. This situation created a real problem for RPM based systems. Users often found that when installing an RPM for a particular application it needed other RPMs (often libraries). Fair enough, start installing the dependencies, but then they need packages that you don’t have installed or are out of date. You are now traversing the RPM dependency tree, which is no fun. To solve this problem Yellowdog Updater, Modified (YUM) was created. Don’t worry about the name, just say “yum.” Using YUM it is possible to install an RPM and all the dependent packages with one command. Of course, you had to tell YUM where to find the “YUM ready” repositories on the web for your particular distribution. Once YUM finds the repositories, it will work out the dependencies and install the needed RPMs from the repository. It all works rather well. By the way, Debian did this first.
RPM and YUM have made distribution management very easy and have reduced headaches. (Although to be fair some argue that they increases headaches!) In addition, I find making my own cluster RPMs makes managing clusters easier as well.
As an example, consider MPI libraries. Some distributions include these as standard RPMs. There are two reasons I don’t use these and build my own RPMs. First, I often want the latest version, which is usually not available, and I want to control where the libraries are placed and configured. Most clusters want at least MPICH2 and Open-MPI installed (and often others). These packages need to be integrated into the environment so that they don’t interfere with one another.
Because I work with a bunch of different clusters and I like consistency, I can install and manage things easier. In addition, Using RPM is a great way to document and remember how a package is installed. I can include configuration (installation and de-installation) scripts directly in the RPM as well as comments and notes about the package. In addition, to MPI libraries, I have batch schedulers, monitors, libraries, etc. that are all managed via RPMs. This convenience comes at a price because it takes time to create a good RPM, but once built I can easily update it for new versions of the underlying package. I’ll have more about managing various package versions next time.