Last modified 2 years ago Last modified on 08/19/19 14:03:33


RPM is a package management system originally created for use in Red Hat Linux, and now present in derivative systems such as CentOS and Fedora.

The following guide specifically pertains to packaging Earthworm as an RPM on Centos; it is hoped that in the future a similar level of detail may be provided for building RPMs for other distributions.

Setup RPM package environment

In addition to all dependencies and tools that are typically required in order to build Earthworm on Linux (see EarthwormCompile), we will be installing two more packages for the RPM packaging process

sudo yum -y install rpm-build rpmdevtools

The first package provides the tool 'rpmbuild', which will be used to actually build the RPM itself.

The second package will set up the RPM build environment for packaging to take place.

Before taking a look at the configurations for building Earthworm as an RPM, go ahead and set up that build environment:

cd ~

You will see there is now a directory ~/rpmbuild/, with subdirectories 'BUILD', 'BUILDROOT', 'RPMS', 'SOURCES', 'SPECS', and 'SRPMS'

Earthworm RPM configurations

The key file controlling the RPM build process is called a "spec" file, you'll see that on the trunk of the subversion repository there is such a file ('ew.centos.spec') included in the top-level directory 'rpm':

%define name    earthworm
%define version 7.10
%define release 1
%define ewhome "/opt/earthworm"
%define version_dir %{ew_home}/%{name}_%{version}
Summary: Open source seismic data acquisition and automatic earthquake processing software suite
License: Free
Name: earthworm
Vendor: ISTI
Packager: Alexander Schnackenberg (
#Provides: earthworm = %{version}-%{release}
Version: %{version}
Release: %{release}
Source: %{name}_%{version}.tar.gz
BuildRoot: /tmp/earthworm/
BuildRequires: gcc-c++
BuildRequires: gcc-gfortran
Earthworm provides users with an advanced open source seismic data acquisition and processing software
package capable of calculating earthquake locations and magnitudes.

The Earthworm system is a robust a mature software tool, incorporating over 25 years of design and

# set name of build directory to /opt/earthworm, then create and cd to that directory
# %setup -c -n %{ew_home}
%setup -n %{name}_%{version} 

source environment/rpm_env.bash
cd src
make clean_unix
make unix

#broken binaries included with Mole:
rm -rf $RPM_BUILD_DIR/%{name}_%{version}/src/archiving/mole/
rm -rf $RPM_BUILD_DIR/%{name}_%{version}/src/data_sources/gcf2ew/
rm -rf $RPM_BUILD_DIR/%{name}_%{version}/src/data_exchange/sendfile_srv
install -d $RPM_BUILD_ROOT/opt/earthworm/%{name}_%{version}
cp -r $RPM_BUILD_DIR/%{name}_%{version}/ $RPM_BUILD_ROOT/opt/earthworm/


%config /opt/earthworm/%{name}_%{version}/params
%config /opt/earthworm/%{name}_%{version}/environment
%doc /opt/earthworm/%{name}_%{version}/release_notes*
%doc /opt/earthworm/%{name}_%{version}/README*
%docdir /opt/earthworm/%{name}_%{version}/ewdoc

At the top level, a few variables are declared via the '%define' syntax

'version' is set to the "major version" of Earthworm, at the time of this writing it is version 7.10 'release' is a minor or patch version. This is the mechanism by which patches may be made in between major version release

It is important to point out right now that 'version' and 'release' help a package manager tell whether or not it has the latest package installed. If one were to attempt to package some changes but fail to increment either the version number or release number, a package manager on a system that already had installed an Earthworm RPM would refuse to do so.

Further down, we can see that a few variables related to the installation/build environment.

After the initial '%defines', we come to a section with lines starting with capital letters. The initial declarations are in fact not required by the RPM build system, it is the fields that follow (eg, 'Summary', 'License', 'Name' etc) which are actually required by the RPM standard.

We won't go into all of this now, but future packagers are highly encouraged to update the 'Packager' as appropriate. Furthermore, we should pay attention to the line labelled 'Source': this line is telling us that the source code will be available in an archive named "earthworm_7.10.tar.gz". This source archive should be placed in ~/rpmbuild/SOURCES/ based on the setup we did earlier.

Finally, the 'BuildRequires' lines specify that building the RPM requires gcc-c++ and gcc-gfortran. Earlier it was mentioned that one should have all of the prerequisites to build Earthworm on Linux already installed, but in case we forget these two packages are made explicit here.

Skipping the description section, we see there are sections labelled






These directives lay out the process by which the package is to be built. The '%setup' directive takes our archive and unpacks it, creating a directory in ~/rpmbuild/BUILD/ that we've chosen to call "earthworm_7.10"

The '%build' directive lays out the steps for actually building the package. You'll see that there is a special environment file, 'rpm_env.bash' that is sourced before we proceed with the rest of the build process

The %install directive takes what we've build in ~/rpmbuild/BUILD/ and sets up the RPM to be package in ~/rpmbuild/BUILDROOT/. You can see that in this case we've done little more than a recursive copy of the build tree into the BUILDROOT directory.

One issue with this approach is that anything present in the build tree ends up being thrown into the resulting RPM, which could result in the presence of binaries in the resulting RPM package that weren't build on the system in question. This is a problem because the last step of the build package consists of rpmbuild checking for binary dependencies, and binaries built on different systems will often link to different objects or library files.

The '%clean' directive being unused in this instance, we'll skip over to the '%files' section. Here, we simply declare which files we expect to be present upon installation of the package.

Building the Earthworm RPM

Let's walk-through a hypothetical example of needing to build an RPM package for a critical patch. Let's assume that the above spec file is for the latest RPM package available

First, get the latest source code:

svn checkout svn:// earthworm_7.10

Then, edit the spec file earthworm_7.10/rpm/ew.centos.spec to increment the release number:

%define release 2

Don't forget to commit the new spec file to subversion!

Copy the spec file to the rpmbuild tree:

cp earthworm_7.10/rpm/ew.centos.spec ~/rpmbuild/SPECS/

Next, remove the subversion repository information:

rm -rf earthworm_7.10/.svn/

Time to create the source archive:

tar -cvzf ./earthworm_7.10.tar.gz ./earthworm_7.10

Copy the source archive to the rpmbuild tree:

cp earthworm_7.10.tar.gz ~/rpmbuild/SOURCES

Finally, let's build those RPMs!!

rpmbuild -ba ~/rpmbuild/SPECS/ew.centos.spec

When we're done, we should find our RPM packages created in rpmbuild/RPMS/x86_64

ls ~/rpmbuild/RPMS/x86_64/
   earthworm-7.10-2.x86_64.rpm earthworm-debuginfo-7.10-2.x86_64.rpm

Installing the RPM

Take the new RPM and simply run

sudo yum install earthworm-7.10-2.x86_64.rpm

and install with the debug info if desired:

sudo yum install earthworm-debuginfo-7.10-2.x86_64.rpm

The resulting files will be placed in /opt/earthworm/earthworm_7.10/. You will need to run the following command to make them accessible to user 'sysop'(or whatever user will actually need to run the system):

sudo chown -R sysop:sysop /opt/earthworm/earthworm_7.10/

More Information

Obviously, this is just scraping the service of the RPM packaging process, one tailored for the specific issue of packaging Earthworm, and using a spec file that could stand to be cleaned up further.

A more complete guide on working with spec files may be found here:

Wiki on setting up RPM build environment for Centos: