KUSP RPM and rpmbuild Documentation!

This documentation is for Fedora 10/11.

ITTC Specific Practicalities

Due to the disk quotas on home directories at ITTC, most anyone building KUSP RPMS at ITTC will have to follow this workaround.

Step 1): Make a directory in /projects/kurt with your user name and rpmbuild as a child:

bash> mkdir -p /projects/kurt/<your-user-name>/rpmbuild

Step 2): ‘Cd’ into the created directory:

bash> cd /projects/kurt/<your-user-name>/rpmbuild

Step 3): Create all of the expected rpmbuild child directories:


Step 4): Link your home directory to the new quota free rpmbuild directory:

bash> ln -s /projects/kurt/<your-user-name>/rpmbuild ~/rpmbuild

Now everything should work, and you should not have disk quota issues.

The RPM Specification File

The RPM specification (.spec) file is what is used by the rpmbuild program in order to build a proper RPM of the software you wish to package. There is not anything overly technical about making a RPM .spec file, in fact it is quite simple. The standard RPM .spec file is split up into seven segments: Header, Description, Preparation, Build, Install, (Included) Files, and Cleanup, The Preparation, Build, and Install steps should be familiar since these are mostly a direct copy of what you would do on the command line in order to configure-build-install your software. The Header, Description, and (Included) Files are informational fields whose simplicity will become evident in the following sections.

There are many predefined RPM .spec file macros and environmental variables. Knowing these will make your life much simpler since they have been created over many generational refinements of the RPM creation process. There will be little mention of them in detail here, since most of them are easily found in other documentation (such as the rpmbuild man page, the Fedora Project RPM documentation, etc, some of which have links at the bottom of this documentation.

Also to note, when creating an RPM from your previously unpacked source code, it is extremely important to find and compensate for any time there are stored installation locations within the source code. This is because the initial install of the software is to the location ~/rpmbuild/BUILD_ROOT/<package-name>. The final destination of the compiled binary data should in a folder like /usr or /usr/local. If, for any reason, there are code files that are storing the installation data during configure/build time, it is essential to make sure that there is some workaround (a special RPM build option perhaps) that makes sure that the stored information will reflect the final installation directory, and not the rpmbuild temporary installation directory.

Header (No defining macro)

There is not a macro that defines the start of the header. The header should always be placed at the beginning of the file before all of the other steps in the specification file. Normally, your rpm specification file should include all of the following fields.

  • Name: The name of the software for which you are creating an rpm.
  • Version: The version of the software for which you are making the rpm.
  • Release: The RPM release number of the software for which you are making the rpm.
  • Summary: A one line summary of the software. This is most often viewed in the YUM package manager as the one liner below the name of of the package in the package browser.
  • Group: This should be one of the already defined package groups.
  • License: The name of the software license.
  • URL: Homepage URL for the software.
  • SourceXX: This is the source tarball of each piece of the rpm. XX should be a number starting at 0. This is useful if you are packaging more than one piece of software, or dependent packages, in one release.
  • BuildRoot: The location where all of built source package should be temporarily installed before packaging the binary data into an rpm. We use %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) to define a path under BUILD_ROOT that has the form <package-name>.<version>-<release>.<distrobution>.<architecture>. Also, by default the name of the rpm package is the name of the build root with the .rpm suffix.
  • BuildRequires: A comma separated list of the packages that are needed in order to build the software package from source.
  • Requires: A comma separated list of the packages needed in order to have the installed software function correctly.

Description (%description)

The description should immediately follow the header. The description is defined by the rpm macro %description, and the description should be placed under the %description macro.



This is a description of my software.

Preparation (%prep)

The rpm macro %prep defines the preparation stage of building the software rpm. Here is where you can prepare the build directory by removing the previous builds and unpack the source tarball to ~/rpmbuild/BUILD/<package-name>.

Step 1) Remove the old build directory, if any:

rm -rf %{_builddir}/<name-of-software>

The command ‘rm -rf’ is simply the normal bash remove command. The %{_builddir} is an rpmbuild variable that defaults to be ~/rpmbuild/BUILD.

Step 2) Unpack the source tarball:

%setup -q -n <name-of-software>

This uses the rpm macro %setup. This macro unpacks the source tarball with the name <name-of-software>.tar.gz into the directory ~/rmpbuild/BUILD/<name-of-software>. The argument ‘-q’ specifies to do it quietly, and ‘-n <name-of-software>’ is to specify the name of the source tarball. If the -n argument is not explicitly specified then setup will look for a tarball with the naming convention <name-of-software>.<version>-<release>.tar.gz.

Build (%build)

The Build stage of the RPM spec file follows the preparation stage, and is defined by the RPM macro %build. This is the stage where you should configure and build your software.

See related macro: %make

Install (%install)

The Installation stage of the RPM spec file follows the Build stage, and is defined by the RPM macro %install. During the install stage you will install your software to the %{_builddir}. This is normally done with make install DESTDIR=%{_builddir}.

See related macro: %makeinstall

Cleanup (%cleanup)

The Cleanup stage of the RPM spec file follows the install stage, and is defined by the RPM macro %cleanup. During the Cleanup stage, it is appropriate to cleanup anything extra that the build process has created. For example, make clean.

Files (%files)

Files and directories to include in the rpm package.

The KUSP RPM Specification File


Name:           kusp
Version:        0.9
Release:        5%{?dist}
Summary:        This is KUSP

Group:          Development/Libraries
License:        GPL
URL:            http://www.ittc.ku.edu/kusp
Source0:        kusp.tar.gz
BuildRoot:      %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)

BuildRequires:  cmake,flex,bison,swig,gcc,gcc-c++
Requires:       python-ply gnuplot


KUSP User Level Software. This release includes the KUSP subsystems:
clksync, CCSM (Computation Component Set Manager), Data Streams,
Discovery, Group Scheduling, KUSP Common Components, and NetSpec. The
subsystems provide tools for interacting with the KUSP Kernel as will
as standalone application that can be used regardless if the KUSP
Kernel is installed.

rm -rf %{_builddir}/kusp
%setup -q -n kusp

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT%{_prefix}  -DKERNELROOT=/usr/src/kernels/%(uname -r) -DIS_RPM_BUILD=1
make VERBOSE=1

cd build


Building the RPM

~/rpmbuild Directory

By the new convention the rpmbuild directory is placed under the current user’s home directory. In the child directories of rpmbuild is where all of the rpmbuild magic happens.

BUILD (~/rpmbuild/BUILD)

This is where the build of the source code takes place.


The place to where the build files are placed during the install step for binary RPMS.


Tarball of the source code goes here.

SPECS (~/rpmbuild/SPECS)

Spec files here sometimes.

SRPMS (~/rpmbuild/SRPMS)

Finalized source RPMS are placed here under SRPMS/<architecture>/<package-name>.src.rpm

RPMS (~/rpmbuild/RPMS)

Finalized binary RPMS are placed here under RPMS/<architecture>/<package-name>.rpm

Installing the RPM

sudo rpm -Uvh /<path-to-rpm>/<name-of-package>.rpm

Arguments overview

  • U (Upgrade or Install): Upgrade the package if already installed. If the package is not installed, install the given package.
  • v (Verbose): Run the rpm install verbosely.
  • h (Use hash): Use hash marks to show the progress of the current operation.

Creating RPMS of python packages using distutils

Python distutils can easily create rpm packages of python packages that are setup to use distutils. Be sure to include non-python files in the MANIFEST.in file. The distutils command to create the rpm is:

python setup.py bdist_rpm

The rpm will be located in ./dist.

Setting up a python package to use distutils is beyond the scope of this document but more information is available on the web.


Distutils Binary Distribution

Distutils Source Distribution

References and Sources

  • Hagmans Notes
  • Man page on rpmbuild
  • Fedora project documentation

Indices and tables