Page 275
Page 276
In Chapter 11, "Building Packages: A Simple Example," we packaged a fairly simple application. Since our goal was to introduce package building, we kept things as simple as possible. However, things aren't always that simple in the real world.
In this chapter, we'll package a more complex application that will call on most of RPM's capabilities. We'll start with a general overview of the application and end with a completed package, just as you would if you were tasked with packaging an application that you'd not seen before.
So without further ado, let's meet amanda….
Amanda is a network backup utility. The name amanda stands for Advanced Maryland Automatic Network Disk Archiver. If the word Maryland seems somewhat incongruous, it helps to realize that the program was developed at the University of Maryland by James Da Silva and has subsequently been enhanced by many people around the world.
The sources are available at ftp.cs.umd.edu, in the /pub/amanda directory. At the time of this writing, the latest version of amanda is version 2.3.0. Therefore, it should come as no surprise that the amanda source tar file is called amanda-2.3.0.tar.gz.
As with most network-centric applications, amanda has a server component and a client component. An amanda server controls how the various client systems are backed up to the server's tape drive. Each amanda client uses the operating system's native dump utility to perform the actual backup, which is then compressed and sent to the server. A server can back itself up simply by having the client software installed and configured, just like any other client system.
The software builds with make, and most customization is done in two .h files in the config subdirectory. A fair amount of documentation is available in the doc subdirectory. All in all, amanda is a typical non-trivial application.
Amanda can be built on several UNIX-based operating systems. In this chapter, we'll build and package amanda for Red Hat Linux version 4.0.
Because amanda can be built on numerous platforms, there needs to be some initial customization when first building the software. Since customization implies that mistakes will be made, we'll start off by building amanda without any involvement on the part of RPM.
But before we can build amanda, we have to get it and unpack it.
Page 277
As already mentioned, the home FTP site for amanda is ftp.cs.umd.edu. The sources are in /pub/amanda.
After getting the sources, it's necessary to unpack them. We'll unpack them into RPM's SOURCES directory so we can keep all our work in one place:
# tar zxvf amanda-2.3.0.tar.gz amanda-2.3.0/ amanda-2.3.0/COPYRIGHT amanda-2.3.0/Makefile amanda-2.3.0/README ... amanda-2.3.0/man/amtape.8 amanda-2.3.0/tools/ amanda-2.3.0/tools/munge #
As we saw, the sources unpacked into a directory called amanda-2.3.0. Let's rename that directory to amanda-2.3.0-orig and unpack the sources again:
# ls total 177 drwxr-xr-x 11 adm games 1024 May 19 1996 amanda-2.3.0/ -rw-r--r-- 1 root root 178646 Nov 20 10:42 amanda-2.3.0.tar.gz # mv amanda-2.3.0 amanda-2.3.0-orig # tar zxvf amanda-2.3.0.tar.gz amanda-2.3.0/ amanda-2.3.0/COPYRIGHT amanda-2.3.0/Makefile amanda-2.3.0/README ... amanda-2.3.0/man/amtape.8 amanda-2.3.0/tools/ amanda-2.3.0/tools/munge # ls total 178 drwxr-xr-x 11 adm games 1024 May 19 1996 amanda-2.3.0/ drwxr-xr-x 11 adm games 1024 May 19 1996 amanda-2.3.0-orig/ -rw-r--r-- 1 root root 178646 Nov 20 10:42 amanda-2.3.0.tar.gz #
Now why did we do that? The reason lies in the fact that we will undoubtedly need to make changes to the original sources in order to get amanda to build on Linux. We'll do all our hacking in the amanda-2.3.0 directory and leave the amanda-2.3.0-orig directory untouched.
Since one of RPM's design features is to build packages from the original, unmodified sources, the changes we'll make will need to be kept as a set of patches. The amanda-2.3.0-orig directory will let us issue a simple recursive diff command to create our patches when the time comes.
Now that our sources are unpacked, it's time to work on building the software.
Page 278
Looking at the docs/INSTALL file, we find that the steps required to get amanda configured and ready to build are actually fairly simple. The first step is to modify tools/munge to point to cpp, the C preprocessor.
Amanda uses cpp to create makefiles containing the appropriate configuration information. This approach is a bit unusual, but not unheard of. In munge, we find the following section:
# Customize CPP to point to your system's C preprocessor. # if cpp is on your path: CPP=cpp # if cpp is not on your path, try one of these: # CPP=/lib/cpp # traditional # CPP=/usr/lib/cpp # also traditional # CPP=/usr/ccs/lib/cpp # Solaris 2.x
Since cpp exists in /lib on Red Hat Linux, we need to change this part of munge to
# Customize CPP to point to your system's C preprocessor. # if cpp is on your path: #CPP=cpp # if cpp is not on your path, try one of these: CPP=/lib/cpp # traditional # CPP=/usr/lib/cpp # also traditional # CPP=/usr/ccs/lib/cpp # Solaris 2.x
Next, we need to take a look in config/ and create two files:
There are a number of sample config.h files for a number of different platforms. There is a Linux-specific version, so we copy that file to config.h and review it. After a few changes to reflect our Red Hat Linux environment, it's ready. Now let's turn our attention to options.h.
In the case of options.h, there's only one sample file: options.h-vanilla. As the name implies, this is a basic file that contains a series of #defines that configure amanda for a typical environment. We'll need to make a few changes:
While the first change is pretty much standard fare for anyone used to building software, the last two changes are really due to RPM. With RPM, there's no need to name the programs with a version-specific name, as RPM can easily upgrade to a new version and even downgrade back if the new version doesn't work as well. The default paths amanda uses segregate the files