Библиотека сайта rus-linux.net
| Maximum RPM: Taking the Red Hat Package Manager to the Limit | ||
|---|---|---|
| Prev | Chapter 15. Making a Relocatable Package | Next |
Building a Relocatable Package
cdplayer application. Let's start by reviewing the
spec file for possible problems:
|
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. A prefix of
/usr/local would work pretty well, except for that
cdp-config file.
/usr/local. After these changes are made, let's
try a build:
|
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 the section called The %doc Directive in Chapter 13, 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.
|
The build completed normally. Note how the files to be placed in the
binary package file are listed, minus the prefix of
/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
the section called The %doc Directive in Chapter 13.
Tying Up the Loose Ends
In the course of building this package, we ran into two hitches:
The config file
cdp-configcouldn't be installed in/etc.The
READMEfile could not be packaged using the %doc directive.
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 this package cannot be relocated? Possibly, but there
are two options to consider. The first option is to review the
prefix. In the case of our example, if we chose a prefix of
/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.
[1]
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 post-install 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. [2] 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 using the %post script, the files you move will not verify properly, and when the package is erased, your users will get some disconcerting messages when RPM can't find the moved files to erase them. If you have to resort to these kinds of tricks, it's probably best to forget trying to make the package relocatable.
Test-Driving a Relocatable Package
Looks like cdplayer is a poor candidate for being
made relocatable. However, since we did get a hamstrung version to
build successfully, we can use it to show how to test a relocatable
package.
|
The DEFAULTPREFIX tag directs RPM to display the
prefix used during the build. As we can see, it's
/usr/local, just as we intended. The
--queryformat option is discussed in the section called --queryformat — Construct a Custom Query
Response in Chapter 5.
|
|
|
(We should mention that directories foonly and
blather didn't exist prior to installing
cdplayer.)
|
|
|
bin:
|
cdplay symlink isn't right. What
happened? If we look at cdplayer's makefile, we
see the answer:
|
Ah, when the software is installed during RPM's build process, the
make file sets up the symbolic link. Looking back at the
%files list, we see cdplay
listed. RPM blindly packaged the symlink, complete with its
non-relocatable string. This is why we mentioned absolute symlinks as
a prime example of non-relocatable software.
|
|
Now cdplay will always point to
cdp, no matter where it's installed. When
building relocatable packages, relative symlinks are your friend!
|
|
As you can see, the trickiest part about building relocatable packages is making sure the software you're packaging is up to the task. Once that part of the job is done, the actual modifications are straightforward.
In the next chapter, we'll cover how packages can be built in non-standard directories, as well as how non-root users can build packages.
Notes
| [1] | For more information on the %docdir directive, please see the section called The %docdir Directive in Chapter 13. |
| [2] | Install and erase-time scripts have an environment variable,
|