The -a option works similarly to the -b option, except that the sources are unpacked after changing directory into the top-level build directory. Like the -b option, -a requires -T in order to prevent two sets of unpacking commands. Here are the commands that a %setup -T -a 0 line would produce:

cd /usr/src/redhat/BUILD

rm -rf cdplayer-1.0

cd cdplayer-1.0

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

  if [ $? -ne 0 ]; then

exit $?

fi

cd /usr/src/redhat/BUILD/cdplayer-1.0

chown -R root.root .

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

Note that there is no mkdir command to create the top-level directory prior to issuing a cd into it. In our example, adding the -c option will make things right:

cd /usr/src/redhat/BUILD

rm -rf cdplayer-1.0

mkdir -p cdplayer-1.0

cd cdplayer-1.0

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

if [ $? -ne 0 ]; then

  exit $?

fi

cd /usr/src/redhat/BUILD/cdplayer-1.0

chown -R root.root .

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

The result is the proper sequence of commands for unpacking a tar file with no top-level directory.

If all these interrelated options seem like overkill for unpacking a single source file, you're right. The real reason for the various options is to make it easier to combine several separate source archives into a single, buildable entity. Let's see how they work in that type of environment.

For the purposes of this example, our spec file will have the following three source tags (yes, the source tags should include a URL pointing to the sources):

source: source-zero.tar.gz

source1: source-one.tar.gz

source2: source-two.tar.gz

To unpack the first source is not hard; all that's required is to use %setup with no options:

%setup

This produces the following set of commands:

cd /usr/src/redhat/BUILD

rm -rf cdplayer-1.0

gzip -dc /usr/src/redhat/SOURCES/source-zero.tar.gz | 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 .

If source-zero.tar.gz didn't include a top-level directory, we could have made one by adding the -c option:

%setup -c

which would result in the following:

cd /usr/src/redhat/BUILD

rm -rf cdplayer-1.0

mkdir -p cdplayer-1.0

cd cdplayer-1.0

gzip -dc /usr/src/redhat/SOURCES/source-zero.tar.gz | tar -xvvf -

if [ $? -ne 0 ]; then

  exit $?

fi

cd /usr/src/redhat/BUILD/cdplayer-1.0

chown -R root.root .

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

Of course, if the top-level directory did not match the package name, the -n option could have been added:

%setup -n blather

which results in the following:

cd /usr/src/redhat/BUILD

rm -rf blather

gzip -dc /usr/src/redhat/SOURCES/source-zero.tar.gz | tar -xvvf -

if [ $? -ne 0 ]; then

  exit $?

fi

cd blather

cd /usr/src/redhat/BUILD/blather

chown -R root.root .

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

Or this:

%setup -c -n blather

results in the following:

cd /usr/src/redhat/BUILD

rm -rf blather

mkdir -p blather

cd blather

gzip -dc /usr/src/redhat/SOURCES/source-zero.tar.gz | tar -xvvf -

if [ $? -ne 0 ]; then

  exit $?

fi

cd /usr/src/redhat/BUILD/blather

chown -R root.root .

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

Now let's add the second source file. Things get a bit more interesting here. First, we need to identify which source tag (and, therefore, which source file) we're talking about. So we need to use either the -a or -b option, depending on the characteristics of the source archive. For this example, let's say that -a is the option we want. Adding that option, plus a 1 to point to the source file specified in the source1 tag, we have this:

%setup -a 1

Since we've already seen that using the -a or -b option results in duplicate unpacking, we need to disable the default unpacking by adding the -T option:

%setup -T -a 1

Next, we need to make sure that the top-level directory isn't deleted. Otherwise, the first source file we just unpacked would be gone. That means we need to include the -D option to prevent that from happening. Adding this final option, and including the now complete macro in our %prep script, we now have this:

%setup

%setup -T -D -a 1

This will result in the following commands:

cd /usr/src/redhat/BUILD

rm -rf cdplayer-1.0

gzip -dc /usr/src/redhat/SOURCES/source-zero.tar.gz | 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 .

cd /usr/src/redhat/BUILD

cd cdplayer-1.0

gzip -dc /usr/src/redhat/SOURCES/source-one.tar.gz | tar -xvvf -

if [ $? -ne 0 ]; then

  exit $?

fi

cd /usr/src/redhat/BUILD/cdplayer-1.0

chown -R root.root .

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

So far, so good. Let's include the last source file, but with this one, we'll say that it needs to be unpacked in a subdirectory of cdplayer-1.0 called database. Can we use %setup in this case?

We could, if source-two.tgz creates the database subdirectory. If not, then it'll be necessary to do it by hand. For the purposes of our example, let's say that source-two.tgz wasn't created to include the database subdirectory, so we'll have to do it ourselves. Here's our %prep script now:

%setup

%setup -T -D -a 1

mkdir database

cd database

gzip -dc /usr/src/redhat/SOURCES/source-two.tar.gz | tar -xvvf -

Here's the resulting script:

cd /usr/src/redhat/BUILD

rm -rf cdplayer-1.0

gzip -dc /usr/src/redhat/SOURCES/source-zero.tar.gz | 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 .

cd /usr/src/redhat/BUILD

cd cdplayer-1.0

gzip -dc /usr/src/redhat/SOURCES/source-one.tar.gz | tar -xvvf -

if [ $? -ne 0 ]; then

  exit $?

fi

mkdir database

cd database

gzip -dc /usr/src/redhat/SOURCES/source-two.tar.gz | tar -xvvf -

The three commands we added to unpack the last set of sources were added to the end of the %prep script.

The bottom line to using the %setup macro is that you can probably get it to do what you want, but don't be afraid to tinker. And even if %setup can't be used, it's easy enough to add the necessary commands to do the work manually. Above all, make sure you use the --test option when testing your %setup macros, so you can see what commands they're translating to.

13.4.2. The %patch Macro

The %patch macro, as its name implies, is used to apply patches to the unpacked sources.

In the following examples, our spec file has the following patch tag lines:

patch0: patch-zero

patch1: patch-one

patch2: patch-two

At its simplest, the %patch macro can be invoked without any options:

%patch