Unfortunately, not every application is packaged for every distribution. What do you do when you can't find it packaged for Red Hat Enterprise Linux? If you are like most people, you give up or attempt to install it from source. What happens when installing from source goes badly? If you are like most people, you definitely give up. How do you keep up with application improvements or, perhaps more importantly, security fixes? If you are like most people, you periodically try and check on the application status (especially when your version stops working :) ), and then try and rebuild it. What is the solution to all of these issues? Proper packaging. Well, this post is meant to help you get started.
For many folks, the barrier to entry for RPMs is understanding what exactly "RPM creation" really means. We all know the “point” of an RPM (or packaging in general) is to support dependency management for libraries and applications. However, what does that really mean? What are the pieces of an RPM? What do you need to create one? How do you get started with something small? Everything written about RPMs seems to be geared to doing everything “right” or as if you wanted to package your own application. Sometimes, when you just need to get something installed, you just need the quick and dirty version. Hopefully, this post will get you started with an overview and pointers to next steps.
In short, creating an RPM involves four steps:
- get the application source to build on your system
- take careful notes on what you did while building the application (in what is called a “spec file”)
- create the “RPM creation” directory structure and build the RPM
- try to build/install the app into a pretend, clean system (to test it)
To get started, you should first build a VM that you can dedicate to RPM creation which should simplify your processes. Create a VM with a fresh install of Red Hat Enterprise Linux of whatever version you are targeting. Minor version “shouldn't” matter but it might save you some headaches down the road if you pick the right one. When you create the VM you may want to mount a dedicated virtual disk at /rpm-builds just so you can reuse some of your work if you need to upgrade/downgrade the OS.
Assuming that the first package you want to build is an existing application that just hasn't been packaged or repackaged for Red Hat Enterprise Linux yet, you will likely want to spend some time looking for an existing attempt at packaging the application. If you can find a Source RPM or an existing spec file it will make your life much easier and be a better way to get started. You can search for things like “source rpm <app-name>,” “srpm <app-name>,” or “spec <app-name>” to try and find existing places to start. You can also look at existing spec file repositories for hints, for example the repoforge spec files are stored at github. Finally, you can sometimes find initial attempts at packaging in the “bug lists” for the various repos, for example repoforge issues and EPEL bugs (product “Fedora EPEL”), which may not give you the spec file but lead you to the source control repo that does have it.
Now that you have a bit more of an overview of what is involved in the RPM creation process you can move on to the more definitive guides.
- How to Build an RPM at the Red Hat Customer Portal
- A three part series at IBM DeveloperWorks
- The definitive Fedora How to Create an RPM Guide
- A simple, arbitrary, step-by-step example, the GNU Hello RPM package
In a future post, we will walk through the creation of a simple, but useful, application package.
Last updated: January 9, 2023