Parker Steve. - How to Create an RPM: A practical guide to creating a Linux RPM

Copyright 2016 by Steve Parker. All Rights Reserved. No part of thispublication or the information in it may be quoted from or reproducedin any form by means such as printing, scanning, photocopying orotherwise without prior written permission of the copyright holder.

Linux is the registeredtrademark of Linus Torvalds in the U.S. and other countries.

Red Hat is the registeredtrademark of Red Hat Inc. in the U.S. and other countries.

The RPM Logo on the front cover byCarolingio93 is licensed under the Creative CommonsAttribution-Share Alike 4.0 International, 3.0 Unported, 2.5 Generic,2.0 Generic and 1.0 Generic license.

All trademarks are acknowledged asbelonging to their respective owners.

Dedicated to my wife, Jackie.

Tableof Contents

The formatting conventions in this book are fairlystandard; the main text is in a serif font, like the text you arecurrently reading. System files and commands (such as rpmbuild , /etc/hosts ,and so on) are shown in monospaced font.

Output from interactive sessions is show on alight gray background; commands that you type are in bold text ,for example, here you would type cd and mkdir rpmbuild :

Callout boxes areshown on a lighter background, with a border, and highlightparticular noteworthy items, including a reminder of where you candownload sample files from:

If a line of input istoo long to show on the width of the page of a printed book ,then a backslash ( \ )character is shown to indicate that the command continues onto thenext line (which will be indented). You can either type it inliterally as shown, as multiple lines, like this:

Or you can remove the backslash( \ ) and the line-break, and enter it all one one line, likethis:

Youwill probably find the second option easier. Any shell you are usingwill accept either format.

Attimes, it can be more clear to display the prompt as a single $ symbol, rather than its more usual, but longer format (like [rpm@packagingtake3]$ ), so instead of this:

We will sometimes show thecommands like this, where that makes it easier to read:

Notice that here the additional pwd command confirms that the current location is /home/rpm/files/chapter3/take3 ,since that was no longer clear from the prompt itself.

Thecreation of RPM packages is often seen as a bit of a dark art by manyin the IT industry, particularly those whose main experience andexpertise is somewhere other than the (sometimes quite niche) Linuxdevelopment community. This book is for these people, amongst others:

Developers needing to package up their codeto for distribution

Systems Administrators needing to installand manage software over an estate of servers

DevOps needing to create or modify RPMs fora particular project or environment

Students wanting to learn about and/orexperiment with the mechanisms of RPM

Anybody else who is interested inunderstanding RPMs.

There is some excellent (and free) RPM referencedocumentation online (see the Bibliography), but apparently none thatare particularly accessible to the outsider, or even to the insiderwho just wants to accomplish what should be (and actually is) apretty simple task, without learning any arcane specifics of thedetails of how RPM is implemented.

This book is written for anybody who just wants tobe able to create an RPM package; if you just want to pick up enoughknowledge to get a few files into an RPM, nobody is going to preachat you that you are not exploiting the full, exquisitely jeweledpotential of a finely-honed RPM package. If you do want to learn howto do more with RPM than just install a few files, we'll cover that,too, and go on to cover all of the bits that you may need to knowabout, so you can dip in and out of whichever chapters youparticularly need at any moment. It may well turn out that as youstart to create more and more powerful and flexible RPM packages,that you find yourself wanting to use more and more of its features.

There are many benefits of RPM over,say, distributing a tar ball(.tar compressed archive); this book is more focussed on thepracticality of how to create RPMs than on evangelism of anyparticular technology, but in one word, the key benefit of RPM ismetadata.

The Oxford Dictionary defines Metadata as A setof data that describes and gives information about other data..This is what makes an RPM so much more useful than a tarballor simply copying an executable onto a system. The RPM database keepstrack of what packages are installed, what files and features theyprovide, as well as other information, such as who created them, howthey are licensed, and many other details.

To compare the tarballwith the RPM file, they both contain the required data - theinstalled files - but the RPM also includes lots of extra metadata.Whilst this puts an additional burden on the creator of the RPM, thebenefits are huge, and the up-front cost is relatively low. Once youstart updating your RPM, the benefits increase significantly, and thecost becomes vanishingly small.

By providing a small amount of metadata about thesoftware package, and about the files it contains, you can do farmore with your systems than if you slap software onto them in a morehaphazard way. Just the fact that upgrading the package takes care ofremoving obsolete files as well as deploying new ones, is a massivewin.

Special handling of configuration files within theRPM is another benefit - because RPM knows which files aredocumentation, which are executables, which are configuration files,it can give them special treatment and deal more intelligently withthem.

RPM can also perform custom tasks duringinstallation, removal, upgrades and even downgrades of packages,through the embedding of custom scripts within the package itself.

Yum (and its newer workalike, DNF) is a tool whichworks with repositories of RPMs so as to be able to calculateall of the dependencies between RPMs, and install or upgrade all ofthose along with the RPM that the user requested to be installed. Thefollowing chapter shows the installation of the rpm-buildpackage itself, including automatically downloading the dependenciesfor rpm-build, if you want to see arun-through of how this works.

Installing RPMs by hand is quite possible withoutthe intervention of Yum, but you can quite easily find yourself inRPM Hell - you've found the RPM that you need to install, butit requires some other library, so you have to find and download theRPM for the correct version of that library. Once you've done that,you realise that this second RPM has dependencies of its own, so youhave to find and download them, and so on down the rabbit hole. Yumuses this rich metadata to check and ensure that it can get hold ofall the necessary RPMs to install the package that you need.