A Simplified Look at Basic RPM Packaging

© David Wunderlich, 2006

Preliminary Stuff

You should be doing all of this logged in as a standard user and not as root.

You will have some root windows open during this process if you do things as I do. If you haven't been told before, you should always be careful when doing things as root. I would suggest changing the color scheme for the root account, either by logging in as root or by running "kcontrol" (without the quotes) from a root terminal. Doing this helps me a lot because it's a lot easier to distinguish root and non-root windows from each other.

Most programs compile using the "standard" way of the three commands: ./configure, make, and make install. Some, most notably Python-based programs, do not. Such programs are beyond the scope of this article because I don't know enough to give good advice in the matter.

If a program asks for a newer version of a library that is already in the repositories, be very careful when thinking about upgrading it yourself. You could hose your system very easily. Often times the best move in such circumstances is to be patient, note the need for the library update in order to build the package, and wait for it to show up in the repositories.

Some Lingo

If you're told you need headers of some kind (usually KDE headers), that means you need the development packages for whatever it asked for. Installing the kdebase-devel and kdelibs-devel packages, for example, should resolve KDE headers requests.

If you are told that you need a particular package to compile something, that usually means you need not just the package but also its development package. If a package requires libarts, you may find that libarts is already installed. In order to compile a program that uses it, you must also install libarts-devel.

Intro to Compiling

If you already know about compiling source, you can skip this section.

As stated above, there is a standard way to compile software: using ./configure, make, and make install. It makes more sense to see an example. For this, I'll highlight Solseek, a kicker applet that displays pictures of the sun. Download the source from here:

http://www.kde-apps.org/content/show.php?content=31311

Pick a directory (I use the tmp folder inside my home folder) for compiling sources. It doesn't matter, but it's handy always to do it in the same place so you don't end up with random stuff everywhere. Put the Solseek source here and unpack it with Ark.

Enter the directory and open up a command prompt (in Konqueror, press F4 to open a console for the folder being displayed - a very useful shortcut). Now type "./configure" without the quotes. This will check to make sure you have all of the required libraries for building your application. Install any unmet dependencies from Synaptic, and repeat until you land back at the prompt with no errors.

Now type "make" (without the quotes). Make is one of the GNU utilities and it does all of the dirty work for you when it comes to compiling software. This is the step that takes the longest, and the bigger the source, the longer it takes. Solseek is small and has no complicated dependencies, so this should be fairly quick and painless.

Next, you will need to elevate to root privileges using the "su" command because the next step is installing. Once you having typed in your root password, type "make install" (without the quotes) and it will install your freshly-compiled application. You should now be able to add Solseek to your kicker panel like any other applet. Congratulations, you have successfully compiled and installed a package!

Now we're going to remove Solseek as it will prove useful later and we don't want this installation of it to cause trouble. Remove Solseek from you kicker, then still as root, type "make uninstall" (without the quotes). This will uninstall Solseek. In order for "make uninstall" to work, it must be done from a console in the same directory as the program was compiled, with the source still there. It's not like using apt-get at a root console where the directory doesn't matter.

Where the Magic Happens

RPM packages are always made in the same place in PCLinuxOS - the /usr/src/RPM directory. There are several folders in here to look at:

• The BUILD folder is where sources will be unpacked. You will probably need to go here to manually delete the unpacked sources after building an RPM to prevent wasted space.
• The RPMS folder is where finished RPMs go. Inside are more folders corresponding with processors. The one we're concerned with here is the i586 folder because by default, that's what PCLOS optimizes packages for.
• The SOURCES folder is where sources and spec files go. Spec files will be discussed more in depth later.
• The SPECS folder sometimes holds spec files. I personally don't really use it much, if at all.
• The SRPMS folder is where the SRPMs you build will go.

A Quick Note on SRPMs

SRPMs are source packages done up RPM-style so it's easy to compile them. They have .src.rpm file extensions. In order to compile one into an RPM, simply place the SRPM in the SOURCES folder, and from there as root type "rpm --rebuild foo-1.2.3-1.src.rpm" where foo-1.2.3.src.rpm is the one you want to compile.

SRPMs are easily unpacked using this command:

rpm2cpio foo-1.2.3-1.src.rpm | cpio -idmv --no-absolute-filenames

where once again foo-1.2.3-1.src.rpm is the SRPM you wish to compile. This will yield the sources used and the spec file. Using others' SRPMs is often a great place to start. For building PCLOS RPMs, start with Mandriva SRPMs because the spec files for them are done the same way as are PCLOS's spec files and the library naming scheme between the two is also the same.

A Few Good Links

Official PCLOS source RPMs:

ftp://ftp.tuxmachines.org/pub/pclinuxos/srpms/

PCLOS contrib source RPMs:

http://texsrc.trident.kicks-ass.net/contrib/

Thac's source RPMs:

http://www.mde.djura.org/pclinuxos/2005/SRPMS.thac/

Mandriva source RPMs:

http://mirrors.evolva.ro/mandriva/official/current/SRPMS

RPM Search:

http://rpm.pbone.net/

Spec Files

So what are these spec files anyway? Well, they are the recipe for building RPMs. They have a distinctive way of doing things, but once you get the hang of it, they're not bad.

Grab the Solseek SRPM from here:

http://files.filefront.com/solseek_07_1texsrcrpm/;5269539;;/fileinfo.html

Pardon the ads, but it is free hosting with no bandwidth restrictions.

In any event, copy it to SOURCES, then unpack it using the command from above. The folder will now have three files: the SRPM, the Solseek source, and the solseek.spec file. Open the spec file with your favorite text editor (e.g. Kwrite).

There are certain predefined attributes for RPM files that you must supply, and you can see them in bold now. These should make sense. Sometimes you'll see more than these, sometimes less, but the important thing is getting the important ones covered. Here are a few 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 because it's the first, and tex to signify that it goes with Texstar's distro. You'll need to change this field if you're rebuilding off of others' SRPMs.
• Group: this is the section within Synaptic that the package will appear in.
• For 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 only have to update them once at the top rather than everywhere else they are used throughout the file.
• Under %description is a longer description that will appear in the lower right pane of Synaptic. I find it easiest to fill in this and Summary by copying and pasting material from the website of whatever it is I'm trying to package.
• 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 format as shown. Here is the format in generalities:
  day month date year yourname <your@email.address> version-release - comments about the changes
  If you like, you can change the date to today and the name and email address to yours. If you get something wrong, it will complain about it when building and refuse to do it. Save the spec file and proceed.

Building Your First RPM

For this next part, you'll probably want to have a root-level Konqueror window open (from the K menu: Applications > File Tools > File Manager - Super User Mode). This is why I suggested giving root a different color scheme, because it will stick out like a sore thumb and reduce mistakes. I personally have the following directories open in tabs in that window: SOURCES, your home folder, i586, and SRPMS.

Open up a console in the SOURCES directory (use F4 in Konqueror, remember?) and type "rpm -ba solseek.spec" (without the quotes). This invokes the RPM command line interface in order to build your package. The "-ba" option signifies that you want to build both the RPM and the SRPM; using only a "-b" option will just build the RPM without the source package.

Once this is done, a fresh solseek-0.7-1tex.i586.rpm file will appear in the i586 directory, and a solseek-0.7-1tex.src.rpm file will appear in the SRPMS directory. You can now install the Solseek RPM either by right-clicking and selecting "Open with KPackage" if you have KPackage installed, or at a root console from the i586 directory typing "rpm -i solseek-0.7-1tex.i586.rpm" (without the quotes).

You now should be able to add Solseek to your kicker. If so, then congratulations, you have built your first successful RPM!

Top