Appendix D: Strategies for Dependency Failures


The strategies for dealing with rpm dependency failures can be broken down into two basic categories: automated methods of resolving dependency failures and manual methods. Automated methods are not available, however, when you install packages that are not a part of your distribution. In this appendix, I'll briefly describe how to use one of the automated methods (Yum) after I describe how to resolve dependency failures manually, but first you need to understand what they are and how rpm enforces them.

What are Dependencies?

Programs depend upon shared libraries of program code so that they can make system calls to send output to a device, open files, and so forth.[1] Without shared libraries, every programmer would have to rewrite these basic system operations from scratch every time they developed a new program. When a program is compiled, the programmer links his or her code to these libraries. If the link is static, the compiled shared library object code is added to the program executable; if the link is dynamic, the compiled shared library object code is only loaded by the program when it is needed at run time. Dynamic executables, as they are called, depend upon the correct shared libraries or shared objects for normal operation. rpm dependencies try to enforce the shared object requirements of dynamic executables at installation time so that later—when the program runs—there won't be any problems with the dynamic linking process.

Note 

There is a second type of dependency that rpm enforces based on an explicit entry into the rpm configuration files by the programmer, but for the moment we're not concerned with this type of dependency, which is easy to understand and resolve. We want to focus on the more complex shared object dependencies that rpm enforces.

Dynamic Executables and Shared Objects

Dynamic executables look for shared objects using the shared object name or soname of the library file that was used at the time the program was originally compiled and linked. They look in a few standard places, such as in the /lib and /usr/lib directories and in whatever directories are specified by the LD_LIBRARY_PATH environment variable (see the man page for ld.so for the complete list of possible directories). The shared objects found in these library directories may not be real files, by the way; they might be symbolic links to the real library file located somewhere else (but normally, still in one of the standard library directories).

But the confusing thing—at least from the system administrator's point of view—is that normally there is little relationship between the name of the shared library package that was used to create the shared library file and the name of the shared library file. For example, the GLIBC 2.3 package is used to create the libc.so.6 shared library file. Notice also from this example that the version number tacked on to the end of the shared library file name (.6) is not related to the version number of the package used to create it (2.3). This is intentionally done by the shared library package developers so that a new release of GLIBC, for example, can reuse the same shared library file name, or soname libc.so.6. This allows you to load a new version of GLIBC on your system without breaking all of your programs that are dynamically linked to the libc.so.6 shared library file—assuming, of course, that the new version of GLIBC is backward compatible with the older version of GLIBC that your dynamic executables were originally linked against. So even though the library files, or shared object files, have version numbers associated with them, these version numbers do not help you to determine which version of the shared library package they came from.

Note 

Information about the existing shared objects that were loaded on the system using rpm packages is available when you use the -whatprovides option to the rpm query command.

This confusion is compounded by the fact that a single shared library file may support a range of shared library package versions (for backward compatibility). To examine the GLIBC shared library package version numbers supported by the soname library file /lib/libc.so.6, for example, run the command:

 #objdump --all-headers /lib/libc.so.6 | less 

Scroll down through this report until you reach the Version definitions: section to see which GLIBC versions are supported by your libc.so.6 shared library file:

 Version definitions: 1 0x01 0x0865f4e6 libc.so.6 2 0x00 0x0d696910 GLIBC_2.0 3 0x00 0x0d696911 GLIBC_2.1         GLIBC_2.0 4 0x00 0x09691f71 GLIBC_2.1.1         GLIBC_2.1 5 0x00 0x09691f72 GLIBC_2.1.2         GLIBC_2.1.1 6 0x00 0x09691f73 GLIBC_2.1.3         GLIBC_2.1.2 7 0x00 0x0d696912 GLIBC_2.2         GLIBC_2.1.3 8 0x00 0x09691a71 GLIBC_2.2.1         GLIBC_2.2 9 0x00 0x09691a72 GLIBC_2.2.2         GLIBC_2.2.1 10 0x00 0x09691a73 GLIBC_2.2.3         GLIBC_2.2.2 11 0x00 0x09691a74 GLIBC_2.2.4         GLIBC_2.2.3 12 0x00 0x0963cf85 GLIBC_PRIVATE :        GLIBC_2.2.4 13 0x00 0x0b792650 GCC_3.0 

In this example, the libc.so.6 shared library file supports all the dynamic executables that were originally developed for GLIBC versions 2.0 through 2.2.4.

Note 

You can also use the objdump command to extract the soname from a shared library file with a command like this:

 #objdump --all-headers /lib/libcrypto.so.0.9.6b | grep SONAME 

Next, I'll discuss how the rpm package is built so that these shared library dependencies are known when the rpm package is installed on a new system.

[1]Shared libraries exist for a wide variety of things not limited to system calls.



The Linux Enterprise Cluster. Build a Highly Available Cluster with Commodity Hardware and Free Software
Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software
ISBN: 1593270364
EAN: 2147483647
Year: 2003
Pages: 219
Authors: Karl Kopper

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net