Creating RPM Packages | SUSE Linux 10.0 Unleashed

You have created this wonderful piece of software that you want to share with the rest of the Linux world. Because you are a kind and considerate programmer, you want to make it easy for nonprogrammers to install and run it on their systems. The best way to do this, especially on a SUSE Linux system, is to build an installation package with RPM.

You learned the basics of the RPM system in Chapter 21, "Keeping Your System Current: Package Management." That section looked at RPM from the user's standpoint: the standard way of installing software on SUSE Linux. In this section, you'll get a brief introduction to how to create RPM packages from your source code. You'll find a more detailed approach, with everything you need to know, by reading Ed Bailey's Maximum RPM at http://www.rpm.org/max-rpm.

You can make an RPM package out of any program for which you have working source code. This means you can use programs you have created, but also any other open source program you think needs an RPM. Helping to package new RPMs for a project is an easy, excellent way to contribute to the open-source community. The process is quite simple:

Obtain the source code for the application.
Build the program source.
If necessary, make a patch including any changes required to build the code successfully if the original would not build on your system.
Ensure that the necessary RPM-specific directories exist somewhere on your system: BUILD, SOURCES, SPECS, RPMS, and SRPMS.
Create a spec file for your package.
Build the RPM package.
Test the package.

As a sample project, let's make an RPM for the "Hello World" application you wrote using KDevelop.

Making a Spec File

Because you already have a working KHello program compiled from source, the first three steps in the process are complete. The key step is creating the spec file that tells the rpm application how to install KHello on someone's system. The spec file can be created using any text editor.

There are eight sections in an RPM spec file: a header, a prep section, a build instruction section, an installation section, file cleanup, pre- and post-installation and optional uninstallation scripts, a list of files in the package, and a changelog.

The header section gives a basic description of the package and has a number of elements. Following is our header section for KHello:

Summary: "Hello World" for KDE Name: khello Version: 0.1 Release: 1 Copyright: GPL Group: Applications/Games Source: /home/mikemc/source/KHello/KHello.tgz Distribution: SuSE Linux %description KHello prints the words "Hello World" in a KDE window.

The summary element is a one-line description of our RPM package. The application's name and version are identified using name and version, respectively. A release number is used to identify sequential bug fixes if the extent of the recoding doesn't warrant a version increase. The program's licensing can be specified with copyright. The group element is used to identify which section under the K menu a shortcut icon will be placed.

The source element should point to a pristine copy of our source code (without any patches applied). More than one file can be specified by using source0, source1, source2, and so on. If you did need to apply a patch, those should be listed in the same manner as the source code using the Patch element.

The %description allows us to insert a complete description of what our application does; it can take up more than one line if necessary.

With our header section complete, we can now turn our attention to the prep session. The prep session consists of an sh script to prepare the working directory and source code. We can also use predefined RPM macros to perform common tasks. All we'll need to have in our prep section is a reference to RPM's %setup macro:

%prep %setup

If you had a patch file, you would also want to reference the %patch macro on a separate line after %setup.

The Build section is relatively straightforward. You should put any commands here that you would need to use to build the software after you had untarred the source, patched it, and cd'ed into the directory. This is just another set of commands passed to sh, so any legal sh commands can go here (including comments).

Your current working directory is reset in each of these sections to the top level of the source directory, so keep that in mind. You can cd into subdirectories if necessary.

%build make

The Install section works much the same way as Build. Ideally, you can run make install, but if the Makefile doesn't provide the capability to automatically install an application, it will be necessary to write the sh script to accomplish this here.

%install Make install

The Cleanup section is used mostly for testing purposes. Use the %clean macro to remove any leftover files from the BuildRoot directory before running a second time.

You can run pre- or post-installation scripts by using the %pre or %post macros in this section. Similarly, you can run scripts before or after an uninstallation using %preun or %postun.

All the files included in your package must be listed in the Files section. You will generate a file list in your first test build, which you can then copy to this section. There are also some macros to help with this listing, which you can find at http://www.rpm.org/RPM-HOWTO/build.html.

The last section of the spec file is a changelog, listing new features and fixes in this version. Each entry begins with a standard string:

*date +"%a %b %d %Y" <YourName> <YourEmailAddress>

A subsequent line begins with a and lists the changes. For our example, because you're just at the first version, type something like First version. You can enter anything, but the changelog should be as informative as possible.

%changelog *Fri Sep 30 2005 mikemc mikemc@susefan.com - Created first version.

Save this file in the KHello directory, and you're just about ready to go.

Listing Files and Generating Patches

The contents of %files are critical because if a file is not listed, it will not be included in the final RPM package. One way to generate a good file list for your spec file is to get the source to build cleanly without using RPM. To do this, unpack the sources and preserve the directory by changing its name to KHello.orig. Then unpack the source again so you have two directories. Go into the KHello source directory and build it.

If you had to edit any code, you'll need a patch. After you get things to build, clean out the source directory from any files that were made from the configure script. Then cd back out of the source directory to its parent. Use the diff utility to create a patch file:

diff -uNr KHello.orig KHello > KHello-bugfix.patch

This will create a patch for you that you can use in your spec file. Note that the buxfix that you see in the patch name is just an identifier. You might want to use something more descriptive as to why you had to make a patch. It's also a good idea to look at the patch file you are creating before using it to make sure no binaries were included by accident. Afterward, copy the file list generated by the build into your spec file.

Building and Testing Your RPM Package

Now that you have a useful spec file, it's time to copy your files to their proper place in the RPM directories created earlier and build your RPM. The original sources and patches should be copied to the SOURCES directory and the spec file is copied to the SPEC directory.

Build the RPM by entering into the SPEC directory and issuing this command:

rpm -ba khello.spec

The command will build both a binary RPM and a source RPM. If you want only a binary package built, use the -bb argument instead, or use -bs if you want only a source package.

RPM will use the BUILD directory to compile the application from the source code and patches and then place the finished binary package file in RPMS. The finished source package file will be placed in SRPMS. With some good fortune, you should now be able to change into the RPMS directory and run rpm ivh khello.rpm to install your new package.

If possible, try installing the package on at least one other computer. After you have successfully built your RPM, register at freshmeat.net and announce your new application!