Page 219
None of these approaches are very appealing, are they? Some software just doesn't relocate very well. In general, the following things are warning signs that relocation is going to be a problem:
If these kinds of issues crop up, making the software relocatable is going to be tough.
Even assuming that the software is written so that it can be put in a relocatable package, there still might be a problem, which relates not to the relocatable software itself, but to other programs that reference the relocatable software.
For example, there are times when a package needs to execute other programs. This might include backup software that needs to send mail, or a communications program that needs to compress files. If these underlying programs were relocatable, and not installed where other packages expect them, they would be of little use.
Granted, this isn't a common problem, but it can happen. And for the package builder interested in building relocatable packages, it's an issue that needs to be explored. Unfortunately, this type of problem can be the hardest to find.
If, however, a software product has been found to be relocatable, the mechanics of actually building a relocatable package are pretty straightforward. Let's give it a try.
For this example, we'll use our tried-and-true cdplayer application. Let's start by reviewing the spec file for possible problems:
# # Sample spec file for cdplayer app... # Summary:A CD player app that rocks! Name: cdplayer ... %files %doc README /usr/local/bin/cdp /usr/local/bin/cdplay %doc /usr/local/man/man1/cdp.1 %config /etc/cdp-config
Everything looks all right, except for the %files list. There are files in /usr/local/bin, a man page in /usr/local/man/man1, and a config file in /etc. The prefix /usr/local would work pretty well, except for that cdp-config file.
Page 220
For the sake of this first build, we'll declare the config file unnecessary and remove it from the %files list. We'll then add a prefix tag line, setting the prefix to /usr/local. After these changes are made, let's try a build:
# rpm -ba cdplayer-1.0.spec * Package: cdplayer + umask 022 + echo Executing: %prep Executing: %prep + cd /usr/src/redhat/BUILD + cd /usr/src/redhat/BUILD + rm -rf cdplayer-1.0 + gzip -dc /usr/src/redhat/SOURCES/cdplayer-1.0.tgz ... Binary Packaging: cdplayer-1.0-1 Package Prefix = usr/local File doesn't match prefix (usr/local): /usr/doc/cdplayer-1.0-1 File not found: /usr/doc/cdplayer-1.0-1 Build failed. #
The build proceeded normally up to the point of actually creating the binary package.
The Package Prefix = usr/local line confirms that RPM picked up our prefix tag line. But
the build stopped—and on a file called
/usr/doc/cdplayer-1.0-1. But that file isn't even in
the %files list. What's going on?
Take a closer look at the %files list. See the line that reads %doc README? In section 13.6.1 in Chapter 13, "Inside the Spec File," we discussed how the %doc directive creates a directory under /usr/doc. That's the file that killed the build—the directory created by the %doc directive.
Let's temporarily remove that line from the %files list and try again:
# rpm -ba cdplayer-1.0.spec * Package: cdplayer + umask 022 + echo Executing: %prep Executing: %prep + cd /usr/src/redhat/BUILD + cd /usr/src/redhat/BUILD + rm -rf cdplayer-1.0 + gzip -dc /usr/src/redhat/SOURCES/cdplayer-1.0.tgz ... Binary Packaging: cdplayer-1.0-1 Package Prefix = usr/local Finding dependencies... Requires (2): libc.so.5 libncurses.so.2.0 bin/cdp bin/cdplay man/man1/cdp.1 90 blocks Generating signature: 0 Wrote: /usr/src/redhat/RPMS/i386/cdplayer-1.0-1.i386.rpm + umask 022 + echo Executing: %clean
Page 221
Executing: %clean + cd /usr/src/redhat/BUILD + cd cdplayer-1.0 + exit 0 Source Packaging: cdplayer-1.0-1 cdplayer-1.0.spec cdplayer-1.0.tgz 82 blocks Generating signature: 0 Wrote: /usr/src/redhat/SRPMS/cdplayer-1.0-1.src.rpm #
The build completed normally. Note how the files to be placed in the binary package file are listed, minus the prefix /usr/local. Some of you might be wondering why the cdp.1 file didn't cause problems. After all, it had a %doc directive, too. The answer lies in the way the file was specified. Since the file was specified using an absolute path, and that path started with the prefix /usr/local, there was no problem. A more complete discussion of the %doc directive can be found in section 13.6.1 in Chapter 13.
In the course of building this package, we ran into two hitches:
Both of these issues are due to the fact that the files' paths do not start with the default prefix path /usr/local. Does this mean that this package cannot be relocated? Possibly, but there are two options to consider. The first option is to review the prefix. For our example, if we chose the prefix /usr instead of /usr/local, the README file could be packaged using the %doc directive since the default documentation directory is /usr/doc. Another approach would be to use the %docdir directive to define another documentation-holding directory somewhere along the prefix path. (For more information on the %docdir directive, see section 13.6.2 in Chapter 13.)
This approach wouldn't work for /etc/cdp-config, though. To package that file, we'd need to resort to more extreme measures. Basically, this approach would entail packaging the file in an acceptable directory (something under /usr/local) and using the %post postinstall script to move the file to /etc. Pointing a symlink at the config file is another possibility.
Of course, this approach has some problems. First, you'll need to write a %postun script to undo what the %post script does. (Install and erase-time scripts have an environment variable, RPM_INSTALL_PREFIX, that can be used to write scripts that are able to act appropriately if the package is relocated. See section 13.3.2 in Chapter 13 for more information.) A %verifyscript that made sure the files were in place would be nice, too. Second, because the file or symlink wasn't installed by RPM, there's no entry for it in the RPM database. This reduces the utility of RPM's -c and -d options when issuing queries. Finally, if you actually move files around