Page 294
/usr/sbin/amflush /usr/sbin/amlabel /usr/sbin/amrestore /usr/sbin/amtape %dir /usr/lib/amanda/ /usr/lib/amanda/taper /usr/lib/amanda/dumper /usr/lib/amanda/driver /usr/lib/amanda/planner /usr/lib/amanda/reporter /usr/lib/amanda/getconf /usr/lib/amanda/chg-generic /usr/man/man8/amanda.8 /usr/man/man8/amadmin.8 /usr/man/man8/amcheck.8 /usr/man/man8/amcleanup.8 /usr/man/man8/amdump.8 /usr/man/man8/amflush.8 /usr/man/man8/amlabel.8 /usr/man/man8/amrestore.8 /usr/man/man8/amtape.8 %doc README %doc COPYRIGHT %doc docs/INSTALL %doc docs/KERBEROS %doc docs/SUNOS4.BUG %doc docs/SYSTEM.NOTES %doc docs/TAPE.CHANGERS %doc docs/WHATS.NEW %doc docs/MULTITAPE %doc example
You'll note that we neglected to use the %doc directive on the man page files. The reason is that RPM automatically tags any file destined for /usr/man as documentation. Now our spec file has a complete set of tags, the two subpackages are defined, it has build-time scripts that work, and now, %files lists for each subpackage. Why don't we try that build again?
# rpm -ba amanda-2.3.0.spec * Package: amanda * Package: amanda-client * Package: amanda-server ... echo Executing: %build Executing: %build + cd /usr/src/redhat/BUILD + cd amanda-2.3.0 + make Making all in common-src ... + echo Executing: %install Executing: %install + cd /usr/src/redhat/BUILD + cd amanda-2.3.0 + make install Making install in common-src ... + echo Executing: special doc Executing: special doc
Page 295
... Binary Packaging: amanda-client-2.3.0-6 Finding dependencies... Requires (3): libc.so.5 libdb.so.2 dump usr/doc/amanda-client-2.3.0-6 usr/doc/amanda-client-2.3.0-6/COPYRIGHT usr/doc/amanda-client-2.3.0-6/INSTALL ... usr/lib/amanda/sendbackup-gnutar usr/lib/amanda/sendsize 1453 blocks Generating signature: 0 Wrote: /usr/src/redhat/RPMS/i386/amanda-client-2.3.0-6.i386.rpm Binary Packaging: amanda-server-2.3.0-6 Finding dependencies... Requires (2): libc.so.5 libdb.so.2 usr/doc/amanda-server-2.3.0-6 usr/doc/amanda-server-2.3.0-6/COPYRIGHT usr/doc/amanda-server-2.3.0-6/INSTALL ... usr/sbin/amrestore usr/sbin/amtape 3404 blocks Generating signature: 0 Wrote: /usr/src/redhat/RPMS/i386/amanda-server-2.3.0-6.i386.rpm ... Source Packaging: amanda-2.3.0-6 amanda-2.3.0.spec amanda-2.3.0-linux.patch amanda-rpm-instructions.tar.gz amanda-2.3.0.tar.gz 393 blocks Generating signature: 0 Wrote: /usr/src/redhat/SRPMS/amanda-2.3.0-6.src.rpm #
If we take a quick look at the client and server subpackages, we find that, sure enough, this time they contain files:
# cd /usr/src/redhat/RPMS/i386/ # ls -l amanda-* -rw-r--r-- 1 root root 211409 Nov 21 15:56 amanda-client-2.3.0-1.i386.rpm -rw-r--r-- 1 root root 512814 Nov 21 15:57 amanda-server-2.3.0-1.i386.rpm # rpm -qilp amanda-* Name : amanda-client Distribution: (none) Version : 2.3.0 Vendor: (none) Release : 1 Build Date: Thu Nov 21 15:55:59 1996 Install date: (none) Build Host: moocow.rpm.org Group : System/Backup Source RPM: amanda-2.3.0-1.src.rpm Size : 737101 Summary : Client-side Amanda package Description : The Amanda Network Backup system contains software necessary to automatically perform backups across a network. Amanda consists of two packages -- a client (this package), and a server: The client package enable a network-capable system to have its filesystems backed up by a system running the Amanda server.
Page 296
| NOTE: |
In order for a system to perform backups of itself, install both the client and server packages! |
/usr/doc/amanda-client-2.3.0-1 /usr/doc/amanda-client-2.3.0-1/COPYRIGHT /usr/doc/amanda-client-2.3.0-1/INSTALL ... /usr/lib/amanda/sendbackup-gnutar /usr/lib/amanda/sendsize Name : amanda-server Distribution: (none) Version : 2.3.0 Vendor: (none) Release : 1 Build Date: Thu Nov 21 15:55:59 1996 Install date: (none) Build Host: moocow.rpm.org Group : System/Backup Source RPM: amanda-2.3.0-1.src.rpm Size : 1733825 Summary : Server-side Amanda package Description : The Amanda Network Backup system contains software necessary to automatically perform backups across a network. Amanda consists of two package -- a client, and a server (this package): The server package enables a network-capable system to control one or more Amanda client systems performing backups. The server system will direct all backups to a locally attached tape drive. Therefore, the server system requires a tape drive.
| NOTE: |
In order for a system to perform backups of itself, install both the client and server packages! |
/usr/doc/amanda-server-2.3.0-1 /usr/doc/amanda-server-2.3.0-1/COPYRIGHT /usr/doc/amanda-server-2.3.0-1/INSTALL ... /usr/sbin/amrestore /usr/sbin/amtape #
We're finally ready to test these packages!
The system we've built the packages on already has amanda installed. This is due to the build process itself. However, we can install the new packages on top of the already-existing files:
# cd /usr/src/redhat/RPMS/i386 # rpm -ivh amanda-*-1.i386.rpm amanda-client ################################################## amanda-server ################################################## #
Running some tests, it looks like everything is running well. But back in Chapter 11, specifically in section 11.5.2, we mentioned that it is possible to install a newly built package on the build system and not realize that the package is missing files. Well, there's another reason
Page 297
installing the package on the build system for testing is a bad idea. Let's bring our packages to a different system, test them there, and see what happens.
Looks like we're almost through. Let's install the packages on another system that has not previously run amanda, and test it there:
# rpm -ivh amanda-*-1.i386.rpm amanda-client ################################################## amanda-server ################################################## #
The install went smoothly enough, but testing did not. Why? Nothing was set up! The server configuration files, the inetd.conf entry for the client—everything was missing. If we stop and think about it for a moment, it makes sense: We had gone through all those steps on the build system, but none of those steps can be packaged as files.
After following the steps in the installation instructions, everything works. While we could expect users to do most of the grunt work associated with getting amanda configured, RPM does have the capability to run scripts when packages are installed and erased. Why don't we use that feature to make life easier for our users?
At this point in the build process, we're on the home stretch. The software builds correctly and is packaged. It's time to stop looking at things from a "build the software" perspective, and time to starting looking at things from a "package the software" point of view.
The difference lies in looking at the packages from the user's perspective. Does the package install easily, or does it require a lot of effort to make it operative? When the package is removed, does it clean up after itself, or does it leave bits and pieces strewn throughout the filesystem?
Let's put a bit more effort into this spec file and make life easier on our users.
When it comes to needing postinstallation configuration, amanda certainly is no slouch! We'll work on the client first. Let's look at a section of the script we wrote, comment on it, and
move on:
%post client # See if they've installed amanda before... # If they have, none of this should be necessary... if [ "$1" = 1 ]; then