Creating RPM packages in Linux

To manage software on Linux, distributions use packages. The benefit of packages is that during installation, the system traces which files are installed, and that makes it easier to perform management tasks later. It’s always a good idea to bundle custom software in a RPM package before adding it to your Linux servers.  In this tip you'll learn how to create your own RPM packages.

RPM is the default package format for Red Hat Enterprise Linux and SUSE Linux Enterprise Server and their derivatives. If you want to install custom software on multiple Linux servers, creating an RPM package can be useful. Making the RPM package available in a repository makes it easier for all the connected servers to update the software at a later stage.

The RPM package contains two files: a shell script and a README file that contains instructions on how to use the script. If you can create a package with  two files, you can also create larger packages.

Procedure for creating simple RPM packages
Note that a clear distinction is made between user accounts used for certain tasks. A normal user account is typically used because errors that are made while using the root user account may cause you to accidentally wipe too many files from your disk. Follow this procedure to put together your own RPM package:

1. Create a directory structure that contains the files that you want in the RPM. This structure is generally assigned the name of the RPM, including its version number. It doesn’t really matter where this directory resides. In this example, it will go in the home directory of the current user account. Here, we will  name the directory test-1.0. The following commands show how to create and name the directory and put some files in it:

$ mkdir ~/test-1.0
$ cd ~/test-1.0
$ echo echo this is a test > test.sh
$ chmod +x test.sh
$ echo just launch the script > README 

2. Now, all the files that are needed in the RPM package are there. The next step is to create a .tar.gz file that contains the files for the RPM. The directory also makes it easier to create the archive file. This file needs to be in a directory with the name rpmbuild/SOURCES -- which is typically going to be in the user home directory as well. You will also need a .specs file, containing all specifications on how to build the RPM package This .specs file is the core component of your RPM and includes all the instructions on where to put the files from the RPM. The .specs file should be placed in a SPECS directory.

The first cd command makes sure that the rpmbuild directory is created inside the user’s home directory. Execute the following commands as a normal user:

$ cd
$ mkdir -p ~/rpmbuild/SOURCES
$ mkdir -p ~/rpmbuild/SPECS
$ tar -cvzf ~/rpmbuild/SOURCES/test-1.0.tar.gz test-1.0

3. Now that the files are in place, create a specs file as a normal user. The rpmbuild command will find all the required instructions to create the file from here. In recent Red Hat and derivative releases, it's easy to create the specs file: Just use the vim editor to create a file with the .spec extension, and one is created that contains all the required sections. Here's what the file would look like for our test-1.0 rpm (Changes applied to the template appear in bold):

Name:               test
Version:            1.0
Release:           1%{?dist}
Summary:         A test package
Group:              Test Packages
License:            GPL
URL:                 http://test.example.com
Source0:           %{name}-%{version}.tar.gz
BuildRoot:        %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
BuildRequires:   /bin/rm, /bin/mkdir, /bin/cp
Requires:          /bin/bash, /bin/date

%description

Demo package for deployment of one single file

%prerp
%setup -q

%build
#configure
#make %{? _smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT

#make install DESTDIR=$RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/bin
cp myscript $RPM_BUILD_ROOT/usr/local/bin

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-root,root,-)
#%doc
%attr(0755,root,root)/usr/local/bin/myscript

%changelog

* Today
- Creation of initial RPM

There are a few things to keep in mind. All the items preceded by a %, are internal macros. Some of them have been disabled for the sake of this simple demo. Most important of these are the %configure and %make macros, which must be disabled by putting a # in front of their names and by removing the % signs.

The macros in the beginning are self-explanatory. The first important macro is the Source0 definition. This is defined as %{name}-%{version}.tar.gz and must exactly match the name of the tar ball that you've created earlier in this procedure.

Another element is BUILD_ROOT. This is the automatically created environment that the rpmbuild command will use to do its work. Remember that BUILD_ROOT is wiped automatically by default. That’s why it’s so important to not work as the root user while building RPMs. The %build section can also be used for tasks like compiling software.

In the %install section, the script that you created earlier is copied. In this example, it’s just a simple cp command, but for more complicated packages, the tasks will be much more sophisticated.

One last part of the .spec file is the %attr macro, which is used to set the permission mode to 0755 and make user and group root the owner of the installed file.

Now that the .spec file is created, it’s time to perform some final tasks. As user root, install the rpmbuild command. In Red Hat, use yum install rpm-build to do this. Next, make sure that all files are in the right location. The tar archive should be in ~/rpmbuild/SOURCES of the user account that you're going to use to create the package, and the demo.spec file has to be in the ~/rpmbuild/SPECS directory. You can now build the package, using the rpmbuild -ba test.spec command. This creates your RPM file in the ~/rpmbuild/RPMS directory.

ABOUT THE AUTHOR: Sander van Vugt is an author and independent technical trainer, specializing in Linux since 1994. He is also a technical consultant for high-availability (HA) clustering and performance optimization, as well as an expert on SLED 10 administration.