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, where
the name of the game is to get software packaged into binary and source
package files, these commands use an already-existing source package
file as input. Let's take a look at them:

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, the
only file required is the source package file. After the software is
built and installed, the only thing left, other than the newly
installed software, is the original 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.

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.

Package builders find this command especially handy, as it allows them
to create new binary packages using one command, with no additional
cleanups required. There are several times when
--rebuild is normally used:

When the build environment (eg. compilers, libraries, etc.) has
changed.

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.

That completes our overview of the commands used to build packages
with RPM. In the next chapter, we'll look at the various macros that
are available and how they can make life easier for the package
builder.