Page 150
But there's another way. Just follow these steps:
Now use --short-circuit to attempt a compile. Here's an example:
# rpm -bc --short-circuit cdplayer-1.0.spec
* Package: cdplayer
+ umask 022
+ echo Executing: %build
Executing: %build
+ cd /usr/src/redhat/BUILD
+ cd cdplayer-1.0
+ make
gcc -Wall -O2 -c -I/usr/include/ncurses cdp.c
gcc -Wall -O2 -c -I/usr/include/ncurses color.c
gcc -Wall -O2 -c -I/usr/include/ncurses display.c
gcc -Wall -O2 -c -I/usr/include/ncurses misc.c
gcc -Wall -O2 -c -I/usr/include/ncurses volume.c
volume.c: In function `mix_set_volume':
volume.c:67: warning: implicit declaration of function `ioctl'
gcc -Wall -O2 -c -I/usr/include/ncurses hardware.c
gcc -Wall -O2 -c -I/usr/include/ncurses database.c
gcc -Wall -O2 -c -I/usr/include/ncurses getline.c
gcc -o cdp cdp.o color.o display.o misc.o volume.o
hardware.o database.o getline.o -I/usr/include/ncurses
-L/usr/lib -lncurses
groff -Tascii -man cdp.1 | compress >cdp.1.Z
+ exit 0
#
Normally, the -bc option instructs RPM to stop the build after the %build section of the spec file has been executed. By adding --short-circuit, however, RPM starts the build by executing the %build section and stops when everything in %build has been executed.
There is only one other build stage that can be --short-circuited: the install stage. The reason for this restriction is to make it difficult to bypass RPM's use of pristine sources. If it were possible to --short-circuit to -bb or -ba, a package builder might take the easy way out and simply hack at the build tree until the software built successfully, then package the hacked sources. So, RPM will only --short-circuit to -bc or -bi. Nothing else will do.
What exactly does an rpm -bi --short-circuit do, anyway? Like an rpm -bc --short-
circuit, it starts executing at the named stage, which in this case is %install. Note that the build environment must be ready to perform an install before attempting to --short-circuit to the %install stage. If the software installs via make install, make will automatically compile the software anyway.
Page 151
And what happens if the build environment isn't ready and a --short-circuit is attempted? Let's see:
# rpm -bi --short-circuit cdplayer-1.0.spec * Package: cdplayer + umask 022 + echo Executing: %install Executing: %install + cd /usr/src/redhat/BUILD + cd cdplayer-1.0 /var/tmp/rpmbu01157aaa: cdplayer-1.0: No such file or directory Bad exit status #
RPM blindly started executing the %install stage, but came to an abrupt halt when it attempted to change directory into cdplayer-1.0, which didn't exist. After giving a descriptive error message, RPM exited with a failure status. Except for some minor differences, rpm -bc would have failed in the same way.
The --buildarch option is used to override RPM's architecture detection logic. The option is followed by the desired architecture name. Here's an example:
# rpm -ba --buildarch i486 cdplayer-1.0.spec Package: cdplayer ... Binary Packaging: cdplayer-1.0-1 ... Wrote: /usr/src/redhat/RPMS/i486/cdplayer-1.0-1.i486.rpm ... Wrote: /usr/src/redhat/SRPMS/cdplayer-1.0-1.src.rpm #
We've removed most of RPM's output from this example, but the main thing we can see from this example is that the package was built for the i486 architecture, due to the inclusion of the --buildarch option on the command line. We can also see that RPM wrote the binary package in the architecture-specific directory, /usr/src/redhat/RPMS/i486. Using RPM's --queryformat option confirms the package's architecture:
# rpm -qp --queryformat `%{arch}\n'\
> /usr/src/redhat/RPMS/i486/cdplayer-1.0-1.i486.rpm
i486
#
For more information on build packages for multiple architectures, see Chapter 19, "Building Packages for Multiple Architectures and Operating Systems."
Page 152
The --buildos option is used to override RPM's operating system detection logic. The option is followed by the desired operating system name. Here's an example:
# rpm -ba --buildos osf1 cdplayer-1.0.spec ... Binary Packaging: cdplayer-1.0-1 ... Wrote: /usr/src/redhat/RPMS/i386/cdplayer-1.0-1.i386.rpm Source Packaging: cdplayer-1.0-1 ... Wrote: /usr/src/redhat/SRPMS/cdplayer-1.0-1.src.rpm #
There's nothing in the build output that explicitly states that the build operating system has been set to osf1. Let's see if --queryformat will tell us:
# rpm -qp --queryformat `%{os}\n'\
> /usr/src/redhat/RPMS/i386/cdplayer-1.0-1.i386.rpm
osf1
#
The package was indeed built for the specified operating system. For more information on building packages for multiple operating systems, see Chapter 19.
The --sign option directs RPM to add a digital signature to the package being built. Currently, this is done using PGP. Here's an example of --sign in action:
# rpm -ba --sign cdplayer-1.0.spec Enter pass phrase: <passphrase> (not echoed) Pass phrase is good. Package: cdplayer ... Binary Packaging: cdplayer-1.0-1 ... Generating signature: 1002 Wrote: /usr/src/redhat/RPMS/i386/cdplayer-1.0-1.i386.rpm ... Source Packaging: cdplayer-1.0-1 ... Generating signature: 1002 Wrote: /usr/src/redhat/SRPMS/cdplayer-1.0-1.src.rpm #
The most obvious effect of adding the --sign option to a build command is that RPM then asks for your private key's passphrase. After entering the passphrase (which isn't echoed), the build proceeds as usual. The only other difference between this and a nonsigned build is that the Generating signature: lines have a nonzero value.
Page 153
Let's check the source and binary packages we've just created to see if they are, in fact, signed:
# rpm --checksig /usr/src/redhat/SRPMS/cdplayer-1.0-1.src.rpm /usr/src/redhat/SRPMS/cdplayer-1.0-1.src.rpm: size pgp md5 OK # rpm --checksig /usr/src/redhat/RPMS/i386/cdplayer-1.0-1.i386.rpm /usr/src/redhat/RPMS/i386/cdplayer-1.0-1.i386.rpm: size pgp md5 OK #
The fact that there is a pgp in --checksig's output indicates that the packages have been signed.
For more information on signing packages, see Chapter 17, "Adding PGP Signatures to a Package." Appendix G, "An Introduction to PGP," contains information on obtaining and installing PGP.
There are times when it might be necessary to get a more in-depth view of a particular build. By using the --test option, it's easy. When --test is added to a build command, the scripts RPM would normally use to actually perform the build are created and saved for you to review. Let's see how it works:
# rpm -ba --test cdplayer-1.0.spec Package: cdplayer #
Unlike in a normal build, there's not much output. But the --test option has caused a set of scripts to be written and saved for you. Where are they?
If you are using a customized rpmrc file, the scripts will be written to the directory specified by the rpmrc entry tmppath. If you haven't changed this setting, RPM, by default, writes the scripts in /var/tmp. Here they are:
# ls -l /var/tmp total 4 -rw-rw-r-- 1 root root 670 Sep 17 20:35 rpmbu00236aaa -rw-rw-r-- 1 root root 449 Sep 17 20:35 rpmbu00236baa -rw-rw-r-- 1 root root 482 Sep 17 20:35 rpmbu00236caa -rw-rw-r-- 1 root root 552 Sep 17 20:35 rpmbu00236daa #
Each file contains a script that performs a given part of the build. Here's the first file:
#!/bin/sh -e # Script generated by rpm RPM_SOURCE_DIR="/usr/src/redhat/SOURCES" RPM_BUILD_DIR="/usr/src/redhat/BUILD" RPM_DOC_DIR="/usr/doc" RPM_OPT_FLAGS="-O2 -m486 -fno-strength-reduce" RPM_ARCH="i386" RPM_OS="Linux" RPM_ROOT_DIR="/tmp/cdplayer" RPM_BUILD_ROOT="/tmp/cdplayer" RPM_PACKAGE_NAME="cdplayer"