Page 205
Page 206
Since the very first version of RPM hit the streets, one of the side effects of RPM's ease of use was that it made it easier for people to break things. Because RPM made it so simple to erase packages, it became common for people to joyfully erase packages until something broke.
Usually this only bit people once, but even once was too much of a hassle if it could be prevented. With this in mind, the RPM developers gave RPM the capability to
In addition, they made sure RPM was able to display dependency information, as well as warn users if they were attempting to do something that would break a package's dependency requirements.
With these features in place, it became more difficult for someone to unknowingly erase a package and wreak havoc on a system.
We've already alluded to the underlying concept of RPM's dependency processing. It is based on two key factors:
By simply checking these two types of information, you can avoid many problems. For example, if a package requires a capability that is not provided by any already-installed package, that package cannot be installed and expected to work properly.
On the other hand, if a package is to be erased, but its capabilities are required by other installed packages, then it cannot be erased without causing other packages to fail.
As you might imagine, it's not quite that simple. But adding dependency information can be easy. In fact, in most cases, it's automatic!
When a package is built by RPM, if any file in the package's %files list is a shared library, the library's soname is automatically added to the list of capabilities the package provides. The soname is the name used to determine compatibility between different versions of a library.
Note that the soname is not a filename. In fact, no aspect of RPM's dependency processing is based on filenames. Many people new to RPM assume that a failed dependency represents a missing file. This is not the case.
Page 207
Remember that RPM's dependency processing is based on knowing what capabilities are provided by a package and what capabilities a package requires. We've seen how RPM automatically determines what shared library resources a package provides. But does it automatically determine what shared libraries a package requires?
Yes! RPM does this by running ldd on every executable program in a package's %files list. Since ldd provides a list of the shared libraries each program requires, both halves of the equation are complete—that is, the packages that make shared libraries available, and the packages that require those shared libraries, are tracked by RPM. RPM can then take that information into account when packages are installed, upgraded, or erased.
RPM uses two scripts to handle automatic dependency processing. They reside in /usr/bin and are called find-requires and find-provides. We'll take a look at them in a minute, but first let's look at why there are scripts to do this sort of thing. Wouldn't it be better to have this built into RPM itself?
Actually, creating scripts for this sort of thing is a better idea. The reason? RPM has already been ported to a variety of different operating systems. Determining what shared libraries an executable requires, and the soname of shared libraries, is simple, but the exact steps required vary widely from one operating system to another. Putting this part of RPM into a script makes it easier to port RPM.
Let's take a look at the scripts that are used by RPM under the Linux operating system.
14.2.1.1. find-requires: Automatically Determine Shared Library RequirementsThe find-requires script for Linux is quite simple:
#!/bin/sh
# note this works for both a.out and ELF executables
ulimit -c 0
filelist=`xargs -r file | fgrep executable | cut -d: -f1 `
for f in $filelist; do
ldd $f | awk `/=>/ { print $1 }'
done | sort -u | xargs -r -n 1 basename | sort -u
This script first creates a list of executable files. Then, for each file in the list, ldd determines the file's shared library requirements, producing a list of sonames. Finally, the list of sonames is sanitized by removing duplicates and any paths.
Page 208
14.2.1.2. find-provides: Automatically Determine Shared Library SonamesThe find-provides script for Linux is a bit more complex, but still pretty straightforward:
#!/bin/bash
# This script reads filenames from STDIN and outputs any relevant
# provides information that needs to be included in the package.
filelist=$(grep "\\.so" | grep -v "^/lib/ld.so" |
xargs file -L 2>/dev/null | grep "ELF.*shared object" | cut -d: -f1)
for f in $filelist; do
soname=$(objdump -p $f | awk `/SONAME/ {print $2}')
if [ "$soname" != "" ]; then
if [ ! -L $f ]; then
echo $soname
fi
else
echo ${f##*/}
fi
done | sort -u
First, a list of shared libraries is created. Then, for each file on the list, the soname is extracted and cleaned up, and duplicates are removed.
Let's take a widely used program, ls, the directory lister, as an example. On a Red Hat Linux system, ls is part of the fileutils package and is installed in /bin. Let's play the part of RPM during fileutils's package build and run find-requires on /bin/ls. Here's what we'll see:
# find-requires /bin/ls <ctrl-d> libc.so.5 #
The find-requires script returned libc.so.5. Therefore, RPM should add a requirement for libc.so.5 when the fileutils package is built. We can verify that RPM did add ls's requirement for libc.so.5 by using RPM's --requires option to display fileutils's requirements:
# rpm -q --requires fileutils libc.so.5 #
Okay, that's the first half of the equation: RPM automatically detecting a package's shared library requirements. Now let's look at the second half of the equation: RPM detecting packages that provide shared libraries. Since the libc package includes, among others, the shared library /lib/libc.so.5.3.12, RPM would obtain its soname. We can simulate this by using find-provides to print out the library's soname:
# find-provides /lib/libc.so.5.3.12