rpm-guide rpm-guide-rpmbuild-en.xml,NONE,1.1
Stuart Ellis (elliss)
fedora-docs-commits at redhat.com
Tue Oct 4 01:59:32 UTC 2005
Author: elliss
Update of /cvs/docs/rpm-guide
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv955
Added Files:
rpm-guide-rpmbuild-en.xml
Log Message:
--- NEW FILE rpm-guide-rpmbuild-en.xml ---
<!-- $Id: -->
<chapter id="ch-rpmbuild">
<title>Controlling the Build with rpmbuild</title>
<para>
Copyright (c) 2005 by Eric Foster-Johnson. This material may be
distributed only subject to the terms and conditions set forth in
the Open Publication License, v1.0 or later (the latest version is
presently available at http://www.opencontent.org/openpub/).
</para>
<para/>
<para>
In This Chapter
</para>
<para>
*Building with the rpmbuild command
</para>
<para>
*Building RPMs without an external spec file
</para>
<para>
*Working with source RPMs
</para>
<para>
*Optimizing builds
</para>
<para>
*Signing built RPMs
</para>
<para>
The preceding chapters in this Part cover details on how to put
together RPMs. This chapter rounds out the discussion by delving
into more details on the rpmbuild command.
</para>
<para>
You can customize how rpmbuild creates RPMs, and you can use RPM
commands to test and debug your package.
</para>
<sect1>
<title>Building RPMs with the rpmbuild Command</title>
<para>
The rpmbuild command provides a workhorse command for building
RPMs in all sorts of ways. The basic syntax, as shown in Chapter
9, is:
</para>
<para>
rpmbuild -bBuildStage spec_file
</para>
<para>
The BuildStage is a letter, such as c, to prepare and compile the
application, executing through the %build section, or i, to
execute through the %install section. This allows you a good deal
of flexibility for building the entire RPM or stopping at some
point prior to a full build.
</para>
<para>
There’s more to the rpmbuild command, though. Quite a few
additional options allow you to further customize the build.
</para>
<para>
Note
</para>
<para>
As mentioned in Chapter 9, previous versions of the RPM system
used the rpm command with a -b, for build, option. This option is
no longer supported. Use the rpmbuild command to build RPMs.
</para>
<sect2>
<title>Customizing the build</title>
<para>
You can customize the rpmbuild command with the options listed
in Table 12-1.
</para>
<para>
Table 12-1 Extra build options for the rpmbuild command
</para>
<informaltable frame="all">
<tgroup cols="2">
<tbody>
<row>
<entry>
<para>
Option
</para>
</entry>
<entry>
<para>
Usage
</para>
</entry>
</row>
<row>
<entry>
<para>
--buildroot directory
</para>
</entry>
<entry>
<para>
Override the default root directory for building with
directory, generally not very useful since most
packages already name a buildroot
</para>
</entry>
</row>
<row>
<entry>
<para>
--clean
</para>
</entry>
<entry>
<para>
Remove the build tree after building
</para>
</entry>
</row>
<row>
<entry>
<para>
--nobuild
</para>
</entry>
<entry>
<para>
Just test the spec file and do not run the build
</para>
</entry>
</row>
<row>
<entry>
<para>
--rmsource
</para>
</entry>
<entry>
<para>
Remove the sources after the build
</para>
</entry>
</row>
<row>
<entry>
<para>
--rmspec
</para>
</entry>
<entry>
<para>
Remove the spec file after the build
</para>
</entry>
</row>
<row>
<entry>
<para>
--short-circuit
</para>
</entry>
<entry>
<para>
With the -bc or -bi options, jump directly to the
given stage and resume the build from that stage
</para>
</entry>
</row>
<row>
<entry>
<para>
--sign
</para>
</entry>
<entry>
<para>
Sign the package with a GPG signature
</para>
</entry>
</row>
<row>
<entry>
<para>
--target platform
</para>
</entry>
<entry>
<para>
Build for the given platform. May not work if you
don't have the other platform build commands, such as
cross compilers, set up. Can work for Intel platforms
with i386, i686, and so on.
</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>
<sect2>
<title>Testing the build</title>
<para>
One of the most useful options is --nobuild, which tells the
rpmbuild command to not build anything. This may seem silly, but
the --nobuild option is very useful for testing whether your
RPMs can be built. With the --nobuild option, the rpmbuild
command parses the spec file and checks for errors, but does not
run any of the build stages.
</para>
<para>
The --buildroot allows you to specify a different top-level
directory for building, overriding the BuildRoot tag in the spec
file. This means you can build in a separate location, which is
helpful in case there are mistakes. Using a separate directory
means the build won’t get mixed with anything else in the
build root directory.
</para>
</sect2>
<sect2>
<title>Debugging the build</title>
<para>
The --short-circuit option tells the rpmbuild command to restart
at a particular location in the build. Rather than working its
way through all the steps up to the build stage you ask for, the
--short-circuit option allows the rpmbuild command to restart
just at the step you ask for.
</para>
<para>
Note
</para>
<para>
This works with the -bc and -bi options only, as well as the -tc
and -ti options covered later in this chapter.
</para>
<para>
For example, if you run the rpmbuild -bc command to stop after
the %build section, you can use the --short-circuit option to
restart the build at the %build section. If you found a problem
in the %build section and corrected it, you can quickly get
going again by restarting the build at the %build section rather
than extracting all the sources yet again.
</para>
<para>
This option is most useful when you are compiling a package, hit
an error, and fix that error. Without the --short-circuit
option, you’ll likely end up spending a lot of time
recompiling the code you have already compiled.
</para>
<para>
During normal development of an RPM package, you will likely
execute each build section, one at a time, stop, fix any errors
and restart where you left off. You’ll go through this cycle a
number of times before the RPM finally builds right.
</para>
<para>
Warning
</para>
<para>
Never distribute an RPM made with the --short-circuit option.
Instead, once you have everything working, start from scratch
and rebuild the RPM. This is to avoid any problems with a
partially-created RPM.
</para>
</sect2>
<sect2>
<title>Cleaning up</title>
<para>
The --clean option tells the rpmbuild command to remove the
build tree when complete. This helps ensure that the next time
you run the rpmbuild command, you are starting from a known
situation.
</para>
<para>
For example:
</para>
<para>
$ rpmbuild --clean /usr/src/redhat/SPECS/jikes.spec
</para>
<para>
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.98247
</para>
<para>
+ umask 022
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ rm -rf jikes-1.17
</para>
<para>
+ exit 0
</para>
<para>
You can use the --clean option alone, as shown previously, or in
concert with another option such as -bi to build and install a
binary RPM. In the latter case, the rpmbuild command will clean
the built files after the rest of the command finishes.
</para>
<para>
Similarly, the --rmsource option tells the rpmbuild command to
remove the sources after completing the command. You can call
this option with another option, such as -bi for building and
installing a binary RPM (and then removing the sources), or
alone on the command line to remove the sources only.
</para>
<para>
For example:
</para>
<para>
rpmbuild --rmsource jikes.spec
</para>
<para>
Note
</para>
<para>
The abbreviation rm is short for remove. It comes from the Linux
rm command, used for removing files.
</para>
<para>
The --rmspec option tells the rpmbuild command to remove the
spec file when done with the command. As with the --rmsource
option, you can use the --rmspec option in conjunction with
another rpmbuild option or on its own to just remove the spec
file.
</para>
<para>
For example:
</para>
<para>
rpmbuild --rmspec jikes.spec
</para>
<para>
Warning
</para>
<para>
The file you are removing with this command is the spec file you
are passing to the command. Be careful, because you cannot undo
this operation and you have now lost your spec file, except
inside your source package.
</para>
</sect2>
<sect2>
<title>Building for other platforms</title>
<para>
The --target option tells the rpmbuild command to build a
package for another platform. You need to pass the name of the
platform. For example:
</para>
<para>
rpmbuild -bi --target i486-redhat-linux
</para>
<para>
The basic format is:
</para>
<para>
cpu-vendor-os
</para>
<para>
For example, i686-redhat-linux specifies a 686 CPU with Red Hat
Linux. Other CPUs include ppc for PowerPC and sparc for Sun
SPARC.
</para>
<para>
Cross Reference
</para>
<para>
The --target option sets the target architecture at build time.
Chapter 4 covers how you can use the --ignoreos and --ignorearch
options when installing RPMs to ignore the operating system and
architecture that is flagged within the RPM. Of course, this
works only if you are installing on a compatible architecture.
</para>
<para>
On the surface level, the --target option overrides some of the
macros in the spec file, %_target, %_target_arch, and
%_target_os. This flags the RPM for the new target platform.
</para>
<para>
Under the covers, setting the architecture macros is not enough.
You really cannot create a PowerPC executable, for example, on
an Intel-architecture machine, unless you have a PowerPC cross
compiler, a compiler that can make PowerPC executables.
</para>
<para>
Warning
</para>
<para>
Set the target with care. Make sure you can really build
executable programs for that architecture.
</para>
<para>
If you try to compile a system that uses the GNU configure
system to configure the build, your target will likely be
ignored. For example, if you try to build the aforementioned
jikes package with a target of ppc-ibm-aix, to specify IBM’s
UNIX, called AIX, on a PowerPC architecture, you will see the
target ignored as the configure system detects that it's running
on Linux on an i686 architecture.
</para>
<para>
For example:
</para>
<para>
$ rpmbuild -bc --target ppc-ibm-aix
/usr/src/redhat/SPECS/jikes.spec
</para>
<para>
Building target platforms: ppc-ibm-aix
</para>
<para>
Building for target ppc-ibm-aix
</para>
<para>
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.94955
</para>
<para>
+ umask 022
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ LANG=C
</para>
<para>
+ export LANG
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ rm -rf jikes-1.17
</para>
<para>
+ /usr/bin/gzip -dc /usr/src/redhat/SOURCES/jikes-1.17.tar.gz
</para>
<para>
+ tar -xf -
</para>
<para>
+ STATUS=0
</para>
<para>
+ '[' 0 -ne 0 ']'
</para>
<para>
+ cd jikes-1.17
</para>
<para>
++ /usr/bin/id -u
</para>
<para>
+ '[' 500 = 0 ']'
</para>
<para>
++ /usr/bin/id -u
</para>
<para>
+ '[' 500 = 0 ']'
</para>
<para>
+ /bin/chmod -Rf a+rX,g-w,o-w .
</para>
<para>
+ exit 0
</para>
<para>
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.15710
</para>
<para>
+ umask 022
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ cd jikes-1.17
</para>
<para>
+ LANG=C
</para>
<para>
+ export LANG
</para>
<para>
+ ./configure CXXFLAGS=-O3 --prefix=/tmp/jikesrpm/usr
</para>
<para>
checking for a BSD-compatible install... /usr/bin/install -c
</para>
<para>
checking whether build environment is sane... yes
</para>
<para>
checking for gawk... gawk
</para>
<para>
checking whether make sets ${MAKE}... yes
</para>
<para>
checking whether to enable maintainer-specific portions of
Makefiles... no
</para>
<para>
checking build system type... i686-pc-linux-gnu
</para>
<para>
checking host system type... i686-pc-linux-gnu
</para>
<para>
checking for g++... g++
</para>
<para>
As you can see, the command starts out with the target as the
platform, but the configure script soon overrides that, as shown
at the end of the truncated output.
</para>
</sect2>
</sect1>
<sect1>
<title>Building RPMs Without an External Spec File</title>
<para>
Most of the options for the rpmbuild command require an RPM spec
file. This file defines all the necessary parameters for the RPM
to build. If you’ve downloaded an application, though, you may
not have all the information needed to build a spec file. In
addition, writing the spec file is the most time-consuming task
when building RPMs. If you are lucky, the provider of a given
application may have already created a spec file and included the
spec file within the source distribution.
</para>
<sect2>
<title>Options for working with tar archives</title>
<para>
A special set of options aims toward building RPMs with spec
files stored in tar archives, also called tarballs. Tarballs are
files combined with the tar (tape archiver) utility and then
optionally compressed, usually with the gzip command. Because
this format is used so often for UNIX and Linux software, you
can use a set of -t options to the rpmbuild command that mimic
the -b options.
</para>
<para>
The basic syntax follows:
</para>
<para>
rpmbuild -tBuildStage compressed_tar_archive
</para>
<para>
The -t option is a lot like the -b option covered in Chapter 9,
except -t tells rpmbuild to build an RPM from a compressed tar
archive instead of from an RPM spec file. You still need a spec
file. These commands just assume that the spec file is located
within the tar archive. The extra BuildStage option is a special
code that tells the rpmbuild command how far to go when
building. Table 12-2 lists these options:
</para>
<para>
Table 12-2 Options for building with rpmbuild with tar archives
</para>
<informaltable frame="all">
<tgroup cols="2">
<tbody>
<row>
<entry>
<para>
Option
</para>
</entry>
<entry>
<para>
Usage
</para>
</entry>
</row>
<row>
<entry>
<para>
-ta
</para>
</entry>
<entry>
<para>
Build all, both a binary and source RPM
</para>
</entry>
</row>
<row>
<entry>
<para>
-tb
</para>
</entry>
<entry>
<para>
Build a binary RPM
</para>
</entry>
</row>
<row>
<entry>
<para>
-tc
</para>
</entry>
<entry>
<para>
Stop after the %build section
</para>
</entry>
</row>
<row>
<entry>
<para>
-tp
</para>
</entry>
<entry>
<para>
Stop after the %prep section
</para>
</entry>
</row>
<row>
<entry>
<para>
-ti
</para>
</entry>
<entry>
<para>
Stop after the %install section
</para>
</entry>
</row>
<row>
<entry>
<para>
-tl
</para>
</entry>
<entry>
<para>
Check the listing of files for the RPM
</para>
</entry>
</row>
<row>
<entry>
<para>
-ts
</para>
</entry>
<entry>
<para>
Build a source RPM only
</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
Note
</para>
<para>
These command-line options work with a tar archive or a
compressed tar archive.
</para>
</sect2>
<sect2>
<title>The expected archive structure</title>
<para>
To build a package this way, the tar archive must have enough of
an expected structure, such as a configure script and a Makefile
with the expected make targets. The most crucial element is that
the tar archive must have the package spec file.That’s because
the rpmbuild command doesn’t know how to build every program
in the universe. Instead, rpmbuild expects to find a spec file
to tell it what to do. If you see an error like the following,
then your tar archive likely is missing the spec file:
</para>
<para>
$ rpmbuild -tc vixie-cron*tar.gz
</para>
<para>
error: Name field must be present in package: (main package)
</para>
<para>
error: Version field must be present in package: (main package)
</para>
<para>
error: Release field must be present in package: (main package)
</para>
<para>
error: Summary field must be present in package: (main package)
</para>
<para>
error: Group field must be present in package: (main package)
</para>
<para>
error: License field must be present in package: (main package)
</para>
<para>
These errors show expected tags from the missing spec file.
</para>
<para/>
<para/>
</sect2>
</sect1>
<sect1>
<title>Working with Source RPMs</title>
<para>
Most of your work with the rpmbuild command will likely be to
create binary RPMs after you have the sources for an application
and a spec file. You can also get a lot of mileage out of source
RPMs, whether you build them or download them.
</para>
<para>
Cross Reference
</para>
<para>
Chapter 10 covers the spec file in depth.
</para>
<para>
Because they are RPMs themselves, source RPMs act like other RPMs.
For example, you can use the rpm -i command to install a source
RPM. This installs the sources provided by the source RPM, not the
actual application. Normally, when you install a source RPM on a
Red Hat Linux system, the package gets installed into
/usr/src/redhat.
</para>
<para>
Note
</para>
<para>
This directory is obviously specific to Red Hat Linux. On other
Linux distributions, you'll likely see directories such as
/usr/src/OpenLinux for SCO (formerly Caldera) OpenLinux.
</para>
<para>
Installing a source RPM is not exactly the same as installing a
binary RPM. For example, the rpm command does not update the RPM
database when you install a source RPM. In addition, listing the
files in a source RPM only shows the relative paths, not the full
paths.
</para>
<para>
Once installation is complete, you can use the rpmbuild command to
create a binary RPM from the sources in the source RPM, using the
-b command-line options introduced in Chapter 9. The next sections
show more shortcuts with source RPMs.
</para>
<sect2>
<title>Rebuilding binary RPMS from source RPMs</title>
<para>
As a shortcut, you do not have to install a source RPM to create
a binary RPM. Instead, you can build the binary RPM directory
using the --rebuild option.
</para>
<para>
The --rebuild option tells the rpmbuild command to rebuild a
binary RPM from a source RPM file. The basic syntax is:
</para>
<para>
rpmbuild --rebuild package.src.rpm
</para>
<para>
This command builds a binary RPM out of a source RPM with a
minimum of fuss. For example:
</para>
<para>
$ rpmbuild --rebuild unix2dos-2.2-17.src.rpm
</para>
<para>
Installing unix2dos-2.2-17.src.rpm
</para>
<para>
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.15828
</para>
<para>
+ umask 022
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ LANG=C
</para>
<para>
+ export LANG
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ rm -rf unix2dos-2.2
</para>
<para>
+ /bin/mkdir -p unix2dos-2.2
</para>
<para>
+ cd unix2dos-2.2
</para>
<para>
+ /usr/bin/gzip -dc /usr/src/redhat/S
OURCES/unix2dos-2.2.src.tar.gz
</para>
<para>
+ tar -xf -
</para>
<para>
+ STATUS=0
</para>
<para>
+ '[' 0 -ne 0 ']'
</para>
<para>
++ /usr/bin/id -u
</para>
<para>
+ '[' 500 = 0 ']'
</para>
<para>
++ /usr/bin/id -u
</para>
<para>
+ '[' 500 = 0 ']'
</para>
<para>
+ /bin/chmod -Rf a+rX,g-w,o-w .
</para>
<para>
+ echo 'Patch #0 (unix2dos-mkstemp.patch):'
</para>
<para>
Patch #0 (unix2dos-mkstemp.patch):
</para>
<para>
+ patch -p1 -b --suffix .sec -s
</para>
<para>
+ echo 'Patch #1 (unix2dos-2.2-segfault.patch):'
</para>
<para>
Patch #1 (unix2dos-2.2-segfault.patch):
</para>
<para>
+ patch -p1 -b --suffix .segf -s
</para>
<para>
+ echo 'Patch #2 (unix2dos-2.2-manpage.patch):'
</para>
<para>
Patch #2 (unix2dos-2.2-manpage.patch):
</para>
<para>
+ patch -p1 -b --suffix .man -s
</para>
<para>
+ perl -pi -e 's,^#endif.*,#endif,g;s,^#else.*,#else,g'
unix2dos.c unix2dos.h
</para>
<para>
+ exit 0
</para>
<para>
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.60650
</para>
<para>
+ umask 022
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ cd unix2dos-2.2
</para>
<para>
+ LANG=C
</para>
<para>
+ export LANG
</para>
<para>
+ gcc -O2 -march=i386 -mcpu=i686 -ounix2dos unix2dos.c
</para>
<para>
+ exit 0
</para>
<para>
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.35128
</para>
<para>
+ umask 022
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ cd unix2dos-2.2
</para>
<para>
+ LANG=C
</para>
<para>
+ export LANG
</para>
<para>
+ rm -rf /var/tmp/unix2dos-root
</para>
<para>
+ mkdir -p /var/tmp/unix2dos-root/usr/bin /var/tmp/unix2dos-
</para>
<para>
root/usr/share/man/man1
</para>
<para>
+ install -m755 unix2dos /var/tmp/unix2dos-root/usr/bin
</para>
<para>
+ install -m444 unix2dos.1
/var/tmp/unix2dos-root/usr/share/man/man1
</para>
<para>
+ /usr/lib/rpm/redhat/brp-compress
</para>
<para>
+ /usr/lib/rpm/redhat/brp-strip
</para>
<para>
+ /usr/lib/rpm/redhat/brp-strip-comment-note
</para>
<para>
Processing files: unix2dos-2.2-17
</para>
<para>
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.12033
</para>
<para>
+ umask 022
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ cd unix2dos-2.2
</para>
<para>
+ DOCDIR=/var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2
</para>
<para>
+ export DOCDIR
</para>
<para>
+ rm -rf /var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2
</para>
<para>
+ /bin/mkdir -p
/var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2
</para>
<para>
+ cp -pr COPYRIGHT
/var/tmp/unix2dos-root/usr/share/doc/unix2dos-2.2
</para>
<para>
+ exit 0
</para>
<para>
Finding Provides: /usr/lib/rpm/find-provides
</para>
<para>
Finding Requires: /usr/lib/rpm/find-requires
</para>
<para>
PreReq: rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames)
</para>
<para>
<= 3.0.4-1
</para>
<para>
Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1
</para>
<para>
rpmlib(CompressedFileNames) <= 3.0.4-1
</para>
<para>
Requires: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1)
</para>
<para>
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/unix2dos-root
</para>
<para>
Wrote: /usr/src/redhat/RPMS/i386/unix2dos-2.2-17.i386.rpm
</para>
<para>
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.47653
</para>
<para>
+ umask 022
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ cd unix2dos-2.2
</para>
<para>
+ rm -rf /var/tmp/unix2dos-root
</para>
<para>
+ exit 0
</para>
<para>
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.47653
</para>
<para>
+ umask 022
</para>
<para>
+ cd /usr/src/redhat/BUILD
</para>
<para>
+ rm -rf unix2dos-2.2
</para>
<para>
+ exit 0
</para>
<para>
With the --rebuild option, the rpmbuild command installs the
source RPM for you and then performs the preparation, compile,
and installation stages of building a binary RPM. Unless there
are errors, you should have a new binary RPM file.
</para>
<para>
When complete, the rpmbuild --rebuild command cleans out the
built files in the build directory, as if the --clean option
were used. The rpmbuild --rebuild command also removes the
installed sources and spec file upon completion.
</para>
</sect2>
<sect2>
<title>Recompiling binaries from source RPMs</title>
<para>
If you just want to recompile the files in a source RPM, you can
use the --recompile option. The --recompile option tells the
rpmbuild command to recompile the binary application from a
source RPM.
</para>
<para>
For example:
</para>
<para>
rpmbuild --recompile package.src.rpm
</para>
<para>
This is the same as installing the source RPM and then running
rpmbuild -bc --clean with the package spec file.
</para>
<para>
Note
</para>
<para>
There is no difference between --recompile and --rebuild in RPM
4.1. RPM 4.2 fixes this problem.
</para>
<para/>
<para/>
</sect2>
<sect2>
<title>SRPMS? Finding source RPMs</title>
<para>
Often, source RPMs are abbreviated as SRPMs. In fact, if you see
a directory named SRPM or SRPMS, chances are the directory holds
source RPMs. (Red Hat uses this convention for its Linux
distributions.)
</para>
<para>
The SRPMS directories on Red Hat CD-ROMs or on the Red Hat FTP
Internet site, ftp.redhat.com, indicate directories that hold
source RPMs.
</para>
</sect2>
</sect1>
<sect1>
<title>Signing Built RPMs</title>
<para>
Signing RPMs adds an extra level of trustworthiness to your RPMs.
A digital signature helps establish that the package comes from
you, really you, and not from someone masquerading as you.
Unfortunately, the RPM system requires a bit of set up work before
you can sign RPMs.
</para>
<sect2>
<title>Checking that the GPG software is installed</title>
<para>
To sign packages, you need to ensure that you have the gpg
command installed and configured. To check that this command is
installed, use a command like the following:
</para>
<para>
$ rpm -qf `which gpg`
</para>
<para>
gnupg-1.0.7-6
</para>
<para>
This shows that the command is available.
</para>
<para>
GPG and PGP? Acronyms Explained
</para>
<para>
The RPM documentation uses GPG and PGP pretty much
interchangeably, so much so, in fact, that you may think these
are typographical errors. Not so.
</para>
<para>
PGP stands for Pretty Good Privacy. Invented by Phil Zimmerman,
PGP was originally invented to encrypt e-mail to allow for
private communication. Based on a public-key cryptography
algorithm, PGP also supports encrypted digital signatures. These
signatures allow you to verify that a package you have
downloaded really comes from the vendor you think it does. You
do this by using the vendor’s public key.
</para>
<para>
GPG stands for GNU Privacy Guard, a free, open-source
implementation of PGP from the GNU project. GPG aims to be
compatible with the OpenPGP Internet standard as defined in RFC
2440. It started when a number of developers wanted a free
implementation. One such free implementation, GPG, allows Linux
vendors such as Red Hat to include PGP in their products. So, in
a sense, GPG provides PGP.
</para>
<para>
PGP has a long and somewhat troubled history as an open-source
product and as a commercial product. See www.philzimmermann.com
for background on PGP and its long history. See www.gnupg.org
for more details on GPG.
</para>
</sect2>
<sect2>
<title>Configuring a signature</title>
<para>
To configure a signature, you first need to create a new key
with the gpg command, using the --gen-key option, as shown
following:
</para>
<para>
$ gpg --gen-key
</para>
<para>
gpg (GnuPG) 1.0.7; Copyright (C) 2002 Free Software Foundation,
Inc.
</para>
<para>
This program comes with ABSOLUTELY NO WARRANTY.
</para>
<para>
This is free software, and you are welcome to redistribute it
</para>
<para>
under certain conditions. See the file COPYING for details.
</para>
<para/>
<para>
gpg: Warning: using insecure memory!
</para>
<para>
gpg: please see http://www.gnupg.org/faq.html for more
information
</para>
<para>
gpg: keyring `/home2/ericfj/.gnupg/secring.gpg' created
</para>
<para>
gpg: keyring `/home2/ericfj/.gnupg/pubring.gpg' created
</para>
<para>
Please select what kind of key you want:
</para>
<para>
(1) DSA and ElGamal (default)
</para>
<para>
(2) DSA (sign only)
</para>
<para>
(4) ElGamal (sign and encrypt)
</para>
<para>
(5) RSA (sign only)
</para>
<para>
Your selection? 1
</para>
<para>
DSA keypair will have 1024 bits.
</para>
<para>
About to generate a new ELG-E keypair.
</para>
<para>
minimum keysize is 768 bits
</para>
<para>
default keysize is 1024 bits
</para>
<para>
highest suggested keysize is 2048 bits
</para>
<para>
What keysize do you want? (1024)
</para>
<para/>
<para>
Requested keysize is 1024 bits
</para>
<para>
Please specify how long the key should be valid.
</para>
<para>
0 = key does not expire
</para>
<para>
<n> = key expires in n days
</para>
<para>
<n>w = key expires in n weeks
</para>
<para>
<n>m = key expires in n months
</para>
<para>
<n>y = key expires in n years
</para>
<para>
Key is valid for? (0)
</para>
<para/>
<para>
You need a User-ID to identify your key; the software constructs
the user id
</para>
<para>
from Real Name, Comment and Email Address in this form:
</para>
<para>
"Heinrich Heine (Der Dichter) <heinrichh at duesseldorf.de>"
</para>
<para/>
<para>
Real name: Eric Foster-Johnson
</para>
<para>
Email address: please_no_spam at nospam.com
</para>
<para>
Comment: Example for Red Hat RPM Guide
</para>
<para>
You selected this USER-ID:
</para>
<para>
"Eric Foster-Johnson (Example for Red Hat RPM Guide)
<erc at no_spam.com>"
</para>
<para>
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
</para>
<para>
O
</para>
<para>
You need a Passphrase to protect your secret key.
</para>
<para/>
<para>
Enter passphrase:
</para>
<para>
We need to generate a lot of random bytes. It is a good idea to
perform
</para>
<para>
some other action (type on the keyboard, move the mouse, utilize
the
</para>
<para>
disks) during the prime generation; this gives the random number
</para>
<para>
generator a better chance to gain enough entropy.
</para>
<para>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
</para>
<para>
+++++++++++++++++++++++++++++++++++..+++++..++++++++++>++++++++++........+++++
</para>
<para>
gpg: /home2/ericfj/.gnupg/trustdb.gpg: trustdb created
</para>
<para>
public and secret key created and signed.
</para>
<para>
key marked as ultimately trusted.
</para>
<para/>
<para>
pub 1024D/01681C24 2002-11-05 Eric Foster-Johnson (Example for
Red Hat RPM
</para>
<para>
Guide) <please_no_spam at nospam.com>
</para>
<para>
Key fingerprint = 8C14 A2E9 47D1 301B 2153 7CDF BEE5 9C10 0268
1D24
</para>
<para>
sub 1024g/1A15D6C8 2002-11-05
</para>
<para>
You can choose the default options for most choices. You need to
enter a real name, an e-mail address, and a pass phrase.
Remember the pass phrase. You will need to enter the pass phrase
every time you wish to sign a package.
</para>
<para>
Once you have a key, the next step is to set up some RPM macros.
There are a number of places you can do this, but using the
.rpmmacros file in your home directory is one of the easiest.
Edit this file as shown in the following example:
</para>
<para>
%_signature gpg
</para>
<para>
%_gpg_path /home2/ericfj/.gnupg
</para>
<para>
%_gpg_name EricFJ (Eric Key) <erc at no_spam.com>
</para>
<para>
%_gpgbin /usr/bin/gpg
</para>
<para>
Add lines like these to the $HOME/.rpmmacros file. (Create this
file if it does not exist.)
</para>
<para>
Cross Reference
</para>
<para>
Chapter 21 covers RPM macros and the $HOME/.rpmmacros file.
</para>
<para>
Inside the file, change the %gpg_path macro to the .gnupg
directory under your home directory (or the root user’s home
directory). Change the %_gpg_name macro to the name you have
entered into the gpg program.
</para>
</sect2>
<sect2>
<title>Signing with the rpmbuild command</title>
<para>
The --sign option tells the rpmbuild command to sign the created
package. You need to have configured the RPM system for your
signature as shown in the previous sections.
</para>
<para>
When you then build an RPM, you will be prompted for your pass
phrase prior to the package build. For example, the following
shows this prompt (and truncates the rest of the rpmbuild
messages that follow):
</para>
<para>
$ rpmbuild -bb --sign xtoolwait-1.2.spec
</para>
<para>
Enter pass phrase:
</para>
<para>
Pass phrase is good.
</para>
</sect2>
<sect2>
<title>Signing with the rpm command</title>
<para>
In addition to the --sign option for the rpmbuild command, you
can sign packages that have already been created using the rpm
command. The --addsign and --resign options generate new
signatures and insert them into the passed-in package file. The
basic syntax is:
</para>
<para>
rpm --addsign package.rpm
</para>
<para>
rpm --resign package.rpm
</para>
<para>
The --addsign option adds another signature to the RPM. RPM
versions prior to 4.1 allowed you to sign a package with
multiple keys, which causes problems for automatic verification.
Because of that, use the --resign option, which removes the old
signature and inserts a new signature into the package.
</para>
</sect2>
<sect2>
<title>Verifying signatures</title>
<para>
You can verify the RPM signature to ensure that the package has
not been modified since it has been signed. Verification also
checks that the package is signed by the key that matches the
claimed vendor.
</para>
<para>
To verify the signature in an RPM, use the -K option to the rpm
command. The basic syntax is:
</para>
<para>
rpm -K package.rpm
</para>
<para>
Note
</para>
<para>
This is the rpm command, not the rpmbuild command.
</para>
<para>
This command accepts the options shown in Table 12-3 to turn off
checking for certain types of signatures.
</para>
<para>
Table 12-3 Options to turn off signature checking
</para>
<informaltable frame="all">
<tgroup cols="2">
<tbody>
<row>
<entry>
<para>
Option
</para>
</entry>
<entry>
<para>
Usage
</para>
</entry>
</row>
<row>
<entry>
<para>
--nogpg
</para>
</entry>
<entry>
<para>
Don’t check for GPG signatures
</para>
</entry>
</row>
<row>
<entry>
<para>
--nomd5
</para>
</entry>
<entry>
<para>
Don’t check for MD5 signatures
</para>
</entry>
</row>
<row>
<entry>
<para>
--nopgp
</para>
</entry>
<entry>
<para>
Don’t check for PGP signatures
</para>
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
You can also use the --checksig option, which is the same as -K.
When you run this command on a package that has a verifiable
key, you will see output like the following:
</para>
<para>
# rpm -K xtoolwait-1.3-3.src.rpm
</para>
<para>
xtoolwait-1.3-3.src.rpm: (sha1) dsa sha1 md5 gpg OK
</para>
<para>
This verifies that the package has not been changed from when it
was first signed. It also verifies that the signature matches
the public key from the vendor of the package. This goes a long
ways toward verifying that the package is indeed legitimate.
</para>
<para>
To get more information, add a -v (verbose) option. For example:
</para>
<para>
$ rpm -Kv vixie-cron-3.0.1-69.src.rpm
</para>
<para>
vixie-cron-3.0.1-69.src.rpm:
</para>
<para>
Header V3 DSA signature: OK, key ID db42a60e
</para>
<para>
Header SHA1 digest: OK
(ecbb244ab022ecd23114bb1d6c9bdeb74f8d9520)
</para>
<para>
MD5 digest: OK (fb0a75eca1d526d391c36dc956c23bdd)
</para>
<para>
V3 DSA signature: OK, key ID db42a60e
</para>
<para>
If you run this command on a package that does not verify,
you’ll see an error like the following:
</para>
<para>
# rpm --checksig xtoolwait-1.3-3.src.rpm
</para>
<para>
xtoolwait-1.3-3.src.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK
(MISSING KEYS: GPG#db42a60e)
</para>
<para>
Items that fail are listed in uppercase, such as DSA, while
items that succeed appear in lowercase. In this example, the
sha1 and md5 tests succeeded, while the DSA test failed. This
failure does not necessarily mean that the package is not
legitimate. This failure can mean one of three things:
</para>
<para>
1.The package was not properly signed in the first place. That
is, it is a legitimate package but the package author did not
properly sign the RPM.
</para>
<para>
2.The package has been modified in some way. That is, the
package is not legitimate.
</para>
<para>
3.The RPM system has not been initialized with the public key
from the package vendor.
</para>
<para>
From this error, you don’t yet know whether the package is
legitimate or not. The first step, though, is to check that you
have imported the proper public key from the package vendor.
</para>
</sect2>
<sect2>
<title>Importing public keys</title>
<para>
The --import option to the rpm command imports the public key
from a given vendor. The format for this key follows:
</para>
<para>
The following public key can be used to verify RPM packages
built and
</para>
<para>
signed by Red Hat, Inc. using `rpm -K' using the GNU GPG
package.
</para>
<para>
Questions about this key should be sent to security at redhat.com.
</para>
<para/>
<para>
-----BEGIN PGP PUBLIC KEY BLOCK-----
</para>
<para>
Version: GnuPG v1.0.0 (GNU/Linux)
</para>
<para>
Comment: For info see http://www.gnupg.org
</para>
<para/>
<para>
mQGiBDfqVEqRBADBKr3Bl6PO8BQ0H8sJoD6p9U7Yyl7pjtZqioviPwXP+DCWd4u8
</para>
<para>
HQzcxAZ57m8ssA1LK1Fx93coJhDzM130+p5BG9mYSPShLabR3N1KXdXAYYcowTOM
</para>
<para>
GxdwYRGr1Spw8QydLhjVfU1VSl4xt6bupPbFJbyjkg5Z3P7BlUOUJmrx3wCgobNV
</para>
<para>
EDGaWYJcch5z5B1of/41G8kEAKii6q7Gu/vhXXnLS6m15oNnPVybyngiw/23dKjS
</para>
<para>
ti/PYrrL2J11P2ed0x7zm8v3gLrY0cue1iSba+8glY+p31ZPOr5ogaJw7ZARgoS8
</para>
<para>
BwjyRymXQp+8Dete0TELKOL2/itDOPGHW07SsVWOR6cmX4VlRRcWB5KejaNvdrE5
</para>
<para>
4XFtOd04NMgWI63uqZc4zkRa+kwEZtmbz3tHSdWCCE+Y7YVP6IUf/w6YPQFQriWY
</para>
<para>
FiA6fD10eB+BlIUqIw80EqjsBKmCwvKkn4jg8kibUgj4/TzQSx77uYokw1EqQ2wk
</para>
<para>
OZoaEtcubsNMquuLCMWijYhGBBgRAgAGBQI36lRyAAoJECGRgM3bQqYOhyYAnj7h
</para>
<para>
VDY/FJAGqmtZpwVp9IlitW5tAJ4xQApr/jNFZCTksnI+4O1765F7tA==
</para>
<para>
=3AHZ
</para>
<para>
-----END PGP PUBLIC KEY BLOCK-----
</para>
<para>
Note
</para>
<para>
For reasons of space, this is not a complete key.
</para>
<para>
You need to pass the name of the text file that holds the key to
the rpm --import command, as shown following:
</para>
<para>
rpm --import key_file
</para>
<para>
Note
</para>
<para>
You must be logged in as the root user to import keys.
</para>
<para>
For example:
</para>
<para>
# rpm --checksig xtoolwait-1.3-3.src.rpm
</para>
<para>
xtoolwait-1.3-3.src.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK
(MISSING KEYS: GPG#db42a60e)
</para>
<para/>
<para>
# rpm --import RPM-GPG-KEY
</para>
<para/>
<para>
# rpm --checksig xtoolwait-1.3-3.src.rpm
</para>
<para>
xtoolwait-1.3-3.src.rpm: (sha1) dsa sha1 md5 gpg OK
</para>
<para>
This example shows an error message when trying to verify the
key. Then, after importing the Red Hat public key, the
verification works.
</para>
<para>
If, after importing this key, you still have problems, you can
assume there are problems with the package. Many administrators
will refuse to install such packages.
</para>
<para>
Warning
</para>
<para>
You should be careful with packages that have signatures that do
not verify.
</para>
<para>
To list the available keys, use a command like the following:
</para>
<para>
$ rpm -qa | grep -i gpg
</para>
<para>
gpg-pubkey-db42a60e-37ea5438
</para>
<para>
This example shows one key installed.
</para>
<para>
Note
</para>
<para>
You can erase this key as if it were a package, using the rpm -e
command.
</para>
</sect2>
<sect2>
<title>Getting the Red Hat public key</title>
<para>
Strangely enough, the Red Hat public key is not installed when
you install Red Hat Linux 8.0. If you need the key, the Red Hat
public key is available on the root directory of all Red Hat
Linux CD-ROMs, as shown in the following listing:
</para>
<para>
$ ls /mnt/cdrom/
</para>
<para>
EULA GPL README RedHat/ RPM-GPG-KEY SRPMS/ TRANS.TBL
</para>
<para>
Simply copy the RPM-GPG-KEY file to get the public key. Then use
the rpm --import command with this key file.
</para>
<para>
Note
</para>
<para>
You can also download this key file from the Red Hat FTP site,
at ftp://ftp.redhat.com/pub/redhat/linux/8.0/en/os/i386/.
</para>
</sect2>
</sect1>
<sect1>
<title>Summary</title>
<para>
This chapter covers options for the rpmbuild command that allow
you to achieve a finer grain of control over how the command
works. For example, the --short-circuit option tells the rpmbuild
command to build just the stages you ask for. This helps when you
have problems in one area of building an RPM and don’t want to
start over each time you try to see if the problem is solved.
</para>
<para>
The rpmbuild command also supports a set of -t options that work
like the -b options, except the -t options try to build an RPM
from a tar archive of sources (a tarball) instead of an RPM spec
file. In this case, the rpmbuild command tries to work without a
spec file.
</para>
<para>
The --rebuild option tells the rpmbuild command to install a
source RPM, build the binary RPM, and clean out the installed
source RPM. This provides quite a shortcut for installing binary
RPMs from source RPMs.
</para>
<para>
RPMs should be signed to provide an extra level of authentication.
This system isn’t perfect, but it helps you verify that a
package is from the person it says it is from and that the package
has not been modified. You can check the signature on RPM packages
you download. You can also, with some configuration, sign the
packages you create.
</para>
<para/>
</sect1>
</chapter>
<!--
Local variables:
mode: xml
sgml-parent-document:("rpm-guide-en.xml" "book" "chapter")
fill-column: 72
End:
-->
More information about the Fedora-docs-commits
mailing list