Linuxdoc Linux Questions
Click here to ask our community of linux experts!
Custom Search

7. Building It

7.1. The Source Directory Tree

The first thing you need is a properly configured build tree. This is configurable using the /etc/rpmrc file. Most people will just use /usr/src.

You may need to create the following directories to make a build tree:

  • BUILD is the directory where all building occurs by RPM. You don't have to do your test building anywhere in particular, but this is where RPM will do it's building.

  • SOURCES is the directory where you should put your original source tar files and your patches. This is where RPM will look by default.

  • SPECS is the directory where all spec files should go.

  • RPMS is where RPM will put all binary RPMs when built.

  • SRPMS is where all source RPMs will be put.

7.2. Test Building

The first thing you'll probably want to to is get the source to build cleanly without using RPM. To do this, unpack the sources, and change the directory name to $NAME.orig. Then unpack the source again. Use this source to build from. Go into the source directory and follow the instructions to build it. If you have to edit things, you'll need a patch. Once you get it to build, clean the source directory. Make sure and remove any files that get made from a configure script. Then cd back out of the source directory to its parent. Then you'll do something like:

diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
      

This will create a patch for you that you can use in your spec file. Note that the "linux" that you see in the patch name is just an identifier. You might want to use something more descriptive like "config" or "bugs" to describe 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.

7.4. Building the Package with RPM

Once you have a spec file, you are ready to try and build your package. The most useful way to do it is with a command like the following:

rpm -ba foobar-1.0.spec
      

There are other options useful with the -b switch as well:

  • p means just run the prep section of the specfile.

  • l is a list check that does some checks on %files.

  • c do a prep and compile. This is useful when you are unsure of whether your source will build at all. It seems useless because you might want to just keep playing with the source itself until it builds and then start using RPM, but once you become accustomed to using RPM you will find instances when you will use it.

  • ido a prep, compile, and install.

  • b prep, compile, install, and build a binary package only.

  • abuild it all (both source and binary packages).

There are several modifiers to the -b switch. They are as follows:

  • --short-circuit will skip straight to a specified stage (can only be used with c and i).

  • --clean removes the build tree when done.

  • --keep-temps will keep all the temp files and scripts that were made in /tmp. You can actually see what files were created in /tmp using the -v option.

  • --test does not execute any real stages, but does keep-temp.

7.5. Testing It

Once you have a source and binary rpm for your package, you need to test it. The easiest and best way is to use a totally different machine from the one you are building on to test. After all, you've just done a lot of make install's on your own machine, so it should be installed fairly well.

You can do an rpm -e packagename on the package to test, but that can be deceiving because in building the package, you did a make install. If you left something out of your file list, it will not get uninstalled. You'll then reinstall the binary package and your system will be complete again, but your rpm still isn't. Make sure and keep in mind that just because you do a rpm -ba package, most people installing your package will just be doing the rpm -i package. Make sure you don't do anything in the build or install sections that will need to be done when the binaries are installed by themselves.