Библиотека сайта rus-linux.net
|Maximum RPM: Taking the Red Hat Package Manager to the Limit|
|Prev||Chapter 14. Adding Dependency Information to a Package||Next|
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 this is not a filename. In fact, no aspect of RPM's dependency processing is based on filenames. Many people new to RPM often make the assumption that a failed dependency represents a missing file. This is not the case.
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
/usr/bin and are called
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.
find-requiresscript for Linux is quite simple:
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 removing any paths.
find-providesscript for Linux is a bit more complex, but still pretty straightforward:
First, a list of shared libraries is created. Then, for each file on the list, the soname is extracted, cleaned up, and duplicates removed.
fileutilspackage and is installed in
/bin. Let's play the part of RPM during
fileutils' package build and run
/bin/ls. Here's what we'll see:
libc.so.5. Therefore, RPM should add a requirement for
fileutilspackage is built. We can verify that RPM did add ls' requirement for
libc.so.5by using RPM's --requires option to display
libcpackage includes, among others, the shared library
/lib/libc.so.5.3.12, RPM would obtain its soname. We can simulate this by using
find-providesto print out the library's soname:
/lib/libc.so.5.3.12's soname is
libc.so.5. Let's see if the
libcpackage really does "provide" the
Yes, there it is, along with the soname of another library contained
in the package. In this way, RPM can ensure that any package
libc.so.5 will have a compatible
library available as long as the
libc.so.5, is installed.
In most cases, automatic dependencies are enough to fill the bill. However, there are circumstances when the package builder has to manually add dependency information to a package. Fortunately, RPM's approach to manual dependencies is both simple and flexible.