Because there will be no blather packages installed once the erase completes, the argument passed to the scripts is 0.

With all that said, of what possible use would this argument be? Well, it has two very interesting properties:

• When the first version of a package is installed, its %pre and %post scripts will be passed an argument equal to 1.
• When the last version of a package is erased, its %preun and %postun scripts will be passed an argument equal to 0.

Given these properties, it's trivial to write an install-time script that can take certain actions in specific circumstances. Usually, the argument is used in the %preun or %postun scripts to perform a special task when the last instance of a package is being erased.

What is normally done during these scripts? The exact tasks may vary, but in general, the tasks are any that need to be performed at these points in the package's existence. One very common task is to run ldconfig when shared libraries are installed or removed. But that's not the only use for these scripts. It's even possible to use the scripts to perform tests to ensure the package install/erasure should proceed.

Since each of these scripts will be executing on whatever system installs the package, it's necessary to choose the script's choice of tools carefully. Unless you're sure a given program is going to be available on all the systems that could possibly install your package, you should not use it in these scripts.

The %pre script executes just before the package is to be installed. It is the rare package that requires anything to be done prior to installation; none of the 350 packages that comprise Red Hat Linux 4.0 make use of it.

The %post script executes after the package has been installed. One of the most popular reasons a %post script is needed is to run ldconfig to update the list of available shared libraries after a new one has been installed. Of course, other functions can be performed in a %post script. For example, packages that install shells use the %post script to add the shell name to /etc/shells.

If a package uses a %post script to perform some function, quite often it will include a %postun script that performs the inverse of the %post script, after the package has been removed.

If there's a time when your package needs to have one last look around before the user erases it, the place to do it is in the %preun script. Anything that a package needs to do immediately prior to RPM taking any action to erase the package can be done here.

The %postun script executes after the package has been removed. It is the last chance for a package to clean up after itself. Quite often, %postun scripts are used to run ldconfig to remove newly erased shared libraries from ld.so.cache.

13.3.3. Verification-Time Script—The %verifyscript Script

The %verifyscript script executes whenever the installed package is verified by RPM's verification command. The contents of this script are entirely up to the package builder, but in general the script should do whatever is necessary to verify the package's proper installation. Since RPM automatically verifies the existence of a package's files, along with other file attributes, the %verifyscript script should concentrate on different aspects of the package's installation. For example, the script might ensure that certain configuration files contain the proper information for the package being verified:

for n in ash bsh; do

    echo -n "Looking for $n in /etc/shells... "

    if ! grep "^/bin/${n}\$" /etc/shells > /dev/null; then

        echo "missing"

        echo "${n} missing from /etc/shells" >&2

    else

        echo "found"

    fi

done

In this script, the config file /etc/shells is checked to ensure that it has entries for the shells provided by this package.

It is worth noting that the script sends informational and error messages to stdout and error messages only to stderr. Normally RPM will only display error output from a verification script; the output sent to stdout is only displayed when the verification is run in verbose mode.

13.4. Macros: Helpful Shorthand for Package Builders

RPM does not support macros in the sense of ad hoc sequences of commands being defined as a macro and executed by simply referring to the macro name.

However, two parts of RPM's build process are fairly constant from one package to another: the unpacking and patching of sources. RPM makes two macros available to simplify these tasks:

• The %setup macro, which is used to unpack the original sources.
• The %patch macro, which is used to apply patches to the original sources.

These macros are used exclusively in the %prep script; it wouldn't make sense to use them anywhere else. The use of these macros is not mandatory—it is certainly possible to write a %prep script without them. But in the vast majority of cases they make life easier for the package builder.

13.4.1. The %setup Macro

As mentioned earlier, the %setup macro is used to unpack the original sources, in preparation for the build. In its simplest form, the macro is used with no options and gets the name of the source archive from the source tag specified earlier in the spec file. Let's look at an example. The cdplayer package has the following source tag:

Source: ftp://ftp.gnomovision.com/pub/cdplayer/cdplayer-1.0.tgz

and the following %prep script:

%prep

%setup

In this simple case, the %setup macro expands into the following commands:

cd /usr/src/redhat/BUILD

rm -rf cdplayer-1.0

gzip -dc /usr/src/redhat/SOURCES/cdplayer-1.0.tgz | tar -xvvf -

if [ $? -ne 0 ]; then

  exit $?

fi

cd cdplayer-1.0

cd /usr/src/redhat/BUILD/cdplayer-1.0 chown -R root.root .

chmod -R a+rX,g-w,o-w .

As you can see, the %setup macro starts by changing directory into RPM's build area and removing any cdplayer build trees from previous builds. It then uses gzip to uncompress the original source (whose name was taken from the source tag), and pipes the result to tar for unpacking. The return status of the unpacking is tested. If successful, the macro continues.

At this point, the original sources have been unpacked. The %setup macro continues by changing directory into cdplayer's top-level directory. The two cd commands are an artifact of %setup's macro expansion. Finally, %setup makes sure every file in the build tree is owned by root and has appropriate permissions set.

But that's just the simplest way that %setup can be used. A number of other options can be added to accommodate different situations. Let's look at them.