| Maximum RPM: Taking the Red Hat Package Manager to the Limit | ||
|---|---|---|
| Prev | Chapter 12. rpm -b Command Reference | Next |
There are two other commands that also perform build-related functions. However, they do not use the rpm -b command syntax that we've been studying so far. Instead of specifying the name of the spec file, as with rpm -b, it's necessary to specify the name of the source package file.
Why the difference in syntax? The reason has to do with the differing functions of these commands. Unlike rpm -b a look at them:
The --recompile option directs RPM to perform the following steps:
Install the specified source package file.
Unpack the original sources.
Build the software.
Install the software.
Remove the software's build directory structure.
While you might think this sounds a great deal like an install of the source package file, followed by an rpm -bi, this is not entirely the case. Using --recompile source package file.
The --recompile option is normally used when a previously installed package needs to be recompiled. --recompile comes in handy when software needs to be compiled against a new version of the kernel.
Here's what RPM displays during a --recompile:
# rpm --recompile cdplayer-1.0-1.src.rpm
Installing cdplayer-1.0-1.src.rpm
* Package: cdplayer
Executing: %prep
…
+ exit 0
Executing: %build
…
+ exit 0
Executing: %install
…
+ exit 0
Executing: special doc
…
+ exit 0
Executing: sweep
…
+ exit 0
#
|
The very first line shows RPM installing the source package. After that are ordinary executions of the %prep, %build, and %install sections of the spec file. Finally, the cleanup of the software's build directory takes place, just as if the --clean option had been specified.
Since rpm -i or rpm -U are not being used to install the software, the RPM database is not updated during a --recompile. This means that doing a --recompile on an already-installed package may result in problems down the road, when RPM is used to upgrade or verify the package.
Package builders, particularly those that create packages for multiple architectures, often need to build their packages starting from the original sources. The --rebuild option does this, starting from a source package file. Here is the list of steps it performs:
Install the specified source package file.
Unpack the original sources.
Build the software.
Install the software.
Create a binary package file.
Remove the software's build directory tree.
Like the --recompile option, --rebuild cleans up after itself. The only difference between the two commands is the fact that --rebuild also creates a binary package file. The only remnants of a --rebuild are the original source package, the newly installed software, and a new binary package file.
several times when --rebuild is normally used:
When the build environment (eg. compilers, libraries, etc.) has changed.
When binary packages for a different architecture are to be built.
Here's an example of the --rebuild option in action:
# rpm --rebuild cdplayer-1.0-1.src.rpm
…
+ exit 0
Executing: %build
…
+ exit 0
Executing: %install
…
+ exit 0
Executing: special doc
…
+ exit 0
Binary Packaging: cdplayer-1.0-1
…
Executing: %clean
…
+ exit 0
Executing: sweep
…
+ exit 0
#
|
The very first line shows RPM installing the source package. The lines after that are ordinary executions of the %prep, %build, and %install sections of the spec file. Next, a binary package file is created. Finally, the spec file's %clean section (if one exists) is executed. The cleanup of the software's build directory takes place, just as if the --clean option had been specified.
life easier for the package builder.
| Главная |