Creating Custom RPMs, Part Two

Roderick Smith

Wednesday, September 15th, 2004

Share This:

Last month’s column looked at the basics of generating RPMs, including the format of the all-important .spec file. In theory, those principles should be enough to let you create .spec files and RPMs for a number of purposes. In practice, however, RPM generation is complex enough that some examples are sure to help. So, this month’s column presents two examples: creating a non-program RPM and creating a program RPM.

Creating a Non-Program RPM

A non-program RPM holds architecture-independent, non-program data. For instance, you might want to create a non-program RPM for fonts that don’t come with your distribution. These might be open source fonts that you’ve downloaded from the Internet, fonts from a commercial source, or fonts you’ve created yourself. In any event, packaging the fonts in an RPM file allows you to easily reinstall the fonts if you need to reinstall the operating system, or to install the fonts on multiple computers. (Of course, you should check license terms before installing commercial fonts on more than one computer.)

To begin the process, you should package the fonts into a carrier file, such as a tarball. The tarball should contain all of the files you want to appear in the final RPM, in their appropriate directories relative to the system root directory.

For example, suppose you want to create a package called myfonts version 1.2.0 that installs files in /usr/share/fonts/myTT/ and /usr/share/fonts/myType1/. The tarball should contain the directories usr/share/fonts/myTT/, usr/share/fonts/myType1/, and all of the…

1. Helpful Tools for Software Developers
2. The Github Hall of Fame
3. Book'em, Github.
4. This Week on Github: Stupid Ruby Tricks
5. A Veritable Scatter Shot!