RPM packaging for beginners

From Granular Linux Documentation

1 Introduction
2 The Basics
3 Get Prepared
4 Two Build Sources
5 Downloads
6 Where to Build
7 Unpacking SRPMs
8 The Spec File
9 A further note on the spec file
10 Building the RPM
11 About Dependencies and Errors
12 References

Introduction

RPM Packaging

Disclaimer: This small how to document is not to be taken as complete documentation on the art of packaging RPMs. That is well beyond the scope of this document and indeed beyond the abilities of the author. As well as I am able to make it so, this how to will be accurate. It is written from both my research and my experience. The methods I describe herein are those that I have used and that have worked for me. It is highly recommended that you do further research on this subject. If you choose to use this document as a guide for packaging RPMs, you do so at your own risk. I wish you great success. -- Merlin Whitewolf

The Basics

From http://rpm.org/ --

"The RPM Package Manager (RPM) is a powerful command line driven package management system capable of installing, uninstalling,
verifying, querying, and updating computer software packages. Each software package consists of an archive of files along with 
information about the package like its version, a description, and the like. There is also a library API, permitting advanced 
developers to manage such transactions from programming languages such as C or Python. “RPM is a core component of many Linux 
distributions, such as Red Hat Enterprise Linux, the Fedora Project, SUSE Linux Enterprise, openSUSE, CentOS, Mandriva Linux, and
many others. It is also used on many other operating systems as well, and the RPM format is part of the Linux Standard Base."

Get Prepared

The first thing you need to do is to prepare your system, that is, you need to install the apps necessary for packaging RPMs. You will also need the dependencies for them.

Open synaptic and click Reload. Go ahead and apply any updates that are available. Click on “Search” and type “RPM” into the field on the search bar. Click to search or simply press the 'Enter' key. This method gives you a smaller 'page' or list of apps to look through.

Look for these packages and install them:

bm (build manager)
rpm build
rpm build update
rpm lint
rpm rebuilder
rpmtools
spechelper

When a pane opens up asking you to include other packages, click Apply. These are dependencies and must be installed along with the RPM building apps. With these installed, you are ready to get started.

Two Build Sources

There are two building resources open for the packaging of RPMs, SRPMs and source tarballs. For the new packager, the source RPM (SRPM – src.rpm) will be much easier to work with. Packaging from a tarball requires much more knowledge and understanding of the RPM building system, including the creation of spec files.

Source RPMs come with an already created spec file. You will need to edit this file to add your information to the changelog, as well as to check to be certain the build arch and other settings are correct (more later). Source tarballs require unpacking, reading through any and all 'readmes' and other documentation to find the information needed to create a spec file. It is not generally recommended that the new packager start with tar files. For those who wish to learn this, further research and study is recommended.

Downloads

Create a “Downloads” folder within your /home directory. Set your browser to download to this folder. This will give you a place to keep up with your source RPM downloads. Within this folder, create the folder “srpms”, if you frequently have other file types downloaded, and move your src.rpms into it.

Source packages are usually available from the same repositories as the installation packages. For example, Mandriva src.rpms may be found here -

http://carroll.cac.psu.edu/pub/linux/distributions/mandrivalinux/official/2007.1/SRPMS/main/release/

There are other places, like http://rpm.pbone.net/ where you may search for sources.

Where to Build

You'll want to work from your /home as much as possible, but you will need to do some work in /root. It is recommended that you use a different colour scheme for /root than you use in your /home. This will be an easy aid in identifying which folder you are in.

Open your File Manager – Superuser Mode and navigate to /usr/src/rpm. Here you will see the folders, BUILD, RPMS, SOURCES, SPECS and SRPMS. The BUILD folder is where the actual building of the RPMs will occur. As this is done automatically, you need do nothing here. The RPMS folder contains the sub-folders, athlon, i386, i486, i586, i686 and noarch. These are the folders where your completed RPMs will be found. SOURCES is where you will put your unpacked src.rpms, including the spec file. (You do not need to use the SPEC folder).

And finally, the SRPMS folder is where you will find your src.rpms after you've built them.

Unpacking SRPMs

Open your file browser to your Downloads folder (or your srpms folder, if you created one). Type the F4 key. This will open a terminal within that folder. Type and enter this command --

rpm2cpio appname-version/releasenumber.src.rpm | cpio -idmv –no- absolute-filenames

Note that it is very important that you get the name and version/release exactly as it is for your downloaded src.rpm. Any errors in the code or name will only result in an error message, not an unpacked SRPM.

Next, move or copy the files (all of them) from your /home/user/Downloads/srpms to /usr/src/rpm/SOURCES.

The Spec File

Note that it is very important that your spec file be correct. An incorrect spec file will result in a failed build.

Open the spec file with kwrite or your favorite text editor.

There are certain predefined attributes for RPM files that must be supplied, and you can see them in bold now. These should make sense. Sometimes you'll see more than these, sometimes less, but the important ones need to be covered.

Here are some notes on some of these:

Summary: This will be displayed in the description field in Synaptic.

Release: This tells what version of the RPM we're on. It says 1 (or other number) because it's the first (or second or third or so on), and tex (if it's from a PCLinuxOS SRPM) to signify that it goes with Texstar's distro. You'll need to change this field to build the package for another distro, like Granular.

Group: This is the section within Synaptic where the package will appear.

Source: you'll see "%{name}-%{version}.tar.bz2" given. %{name} and %{version} are placeholders for the Name and Version fields already defined.

This means you have only to update them once at the top rather than everywhere. These will be used throughout the file. With an SRPM, check to be sure these are correct.

Under %description is a longer description that will appear in the lower right pane of Synaptic. It may be easiest to fill this in, and Summary, by copying and pasting material from the website of whatever it is you're trying to package. If you are using an SRPM, you may not need to edit this.

Check which build arch is set up. PCLinuxOS, as was previously said, uses i586 mostly. If it is set to another build arch, you can change it.

Skip down over the odd-looking stuff to the bottom where %changelog is. This is where people keep track of what changed across each version or release change. The format is standardized, so always keep it in the original format. There will be two lines to fill out. Here is the format:

day month date year yourname <your@email.address> name-version-release
- comments about the changes

At the top of the changes list, with a space between your entry and the previous one, enter the information for the day on which you are packaging the RPM and then the rest of the information. If you get something wrong, it will complain about it when building and refuse to do it. Save the spec file, exit and go on to building the RPM.

Note that if you made any changes to the RPM, you must enter that information on the second line of the entry. If you made no changes other than to package for your distro, the line may read something like, “- rpm packaged for Granular.”

A further note on the spec file

There is a section of the spec file on build requirements (%Build Requires or similar name). These are the packages that you need to have installed in order for this particular package to be built. These are usually devel packages, though sometimes a standard package may be needed as well. If a header file is called for, and you can find no header file of that description, the devel package is most likely what you will need. Devel packages contain header files.

Building the RPM

With File Manager – Superuser Mode still open to /usr/src/rpm/SOURCES, type F4. When the terminal opens type this:

rpm -ba appname.spec

Note that some spec files will have the appname only, while others will have the version/release number as well. It is important that this be entered correctly, so that if for example the spec file is named foo-1.2.spec, you type in foo-1.2.spec.

Your RPM package will be generated. There may be additional RPMs generated, such as lib, devel and debug packages. You will find them in /usr/src/rpm/RPMS/i586 or whichever build arch you used, if not i586. You will also have generated your own SRPM. This will be in /usr/src/rpm/SRPMS.

A note about the build code: The 'rpm' calls for the start of the rpm program and '-b' tells it what to do – i.e. to build. Adding the 'a' to make it '-ba' tells it to package the src.rpm, also. The spec file name tells it where to get its build information.

About Dependencies and Errors

Sometimes the build process ends with an error message. This is something that you will need to address before you can try again. Most often the message will be about a missing dependency. Go ahead and install the missing dependency or dependencies and try again. Pay careful attention to the version number of the dependency. You will want what you install to accurately match what has been called for. When the correct dependency is unavailable, your build will need to wait until it is.

There may be other error messages generated. In each of these cases, you will need to research the error to find a solution, where it is possible. I use this search engine - http://www.google.com/linux