The RPM Package Manager (RPM) has for years stood as one of the core components of many popular Linux Distrobutions. RedHat Enterprise Linux, The Fedora Project, SuSE Linux Enterprise, openSUSE, and a slew of others have long since standardized on using RPM to manage software on the system. To list a few of the key benefits of RPM and other package management systems is not difficult:

• Easily install and un-install software
• Query detailed information of software installed on the system
• RPM packages contain important information headers such as required dependencies, what files/packages might conflict upon installation, list of installed files on the system, and much much more.
• Makes distribution of software far less of a headache than it might be without (which is why so many Linux distributions have adopted it)

Why then, I continually ask, does packaging our own RPMs feel like such a daunting task? As a System Administrator for myself, as well as at work I can admit that I've been in those shoes many times where I have given into the temptation to take the easy route. The "easy route" being to download the source tarball, and run those 3 simple commands:

In nearly 90% of all cases I have encountered this *does* work just fine, no questions asked. The software runs, and the customer is happy. However, How do we manage to properly uninstall said software without leaving hundreds if not thousands of useless, unwanted files lingering on the system? What happens when we overwrite/upgrade software that has previously been installed by RPM? Simple, the RPM database is wrong... and doesn't know that it is wrong. What happens when up2date thinks packageA is at version X.X.y, and relies on X.X.y, but in reality version X.Y.z was compiled and installed from source. Now we potentially are running the risk that not only is our system dirty and not being managed properly, now we have broken our nightly up2date system that keeps us patched and regular.

I could try not to, but am content in saying that compiling and installing software from source on an RPM based distribution is just plain dirty. That's it... tainted, no longer pure.... dirty.

From the other SysAdmins that I have worked with and others I have stood by (and sighed), I would put $5 on the table that says we would rather install from source than have to sit down and learn how to build an RPM Package. And why is that? I wonder what it is that keeps us from wanting to step over that line from the meadows of rpm and into the thick of rpmbuild.

Other than the sheer fact that installing from source is often just so quick and easy, I found out for myself that the documentation on packaging RPMs is not 100%. Don't get me wrong, Max-RPM is a fantastic resource for RPM in general and even more so does a great job of covering the actual build process as well. However, being written in more than 6 years ago leaves it slightly behind the times, as well as severely lacking explanations for techniques I've seen many RPM Developers use... wondering all the while "what-in-the-world does that mean/do"? More than a number of times I found myself in a flood of obscenities, cursing those responsible for documenting the process of packaging software via RPM. For those I have disowned, please forgive me... for it is now that I have found my way. And in return... in my appreciation to you will do my best to enlighten the Linux world of the news: Rolling your own RPMs is not difficult.... what-so-ever! Take 5 minutes to read this, or take 30 to try it out... either way, I am confident that anyone can successfully handle building and/or rebuilding RPM Packages with ease.