Fixing a Dependency Failure Manually


Usually, you will encounter rpm dependency errors when you attempt to install a package that was not included with your distribution (and therefore one that cannot have its dependencies automatically resolved by an update tool such as up2date, apt-get, or Yum).

For example, if you attempt to install all three Heartbeat rpm packages in the chapter7 subdirectory on the CD-ROM using the rpm -ivh *rpm command on an older Linux distribution, you may encounter the following error:

 error: failed dependencies:         libc.so.6(GLIBC_2.3) is needed by heartbeat-1.x.x         libc.so.6(GLIBC_2.3) is needed by heartbeat-pils-1.x.x         libcrypto.so.0.9.6 is needed by heartbeat-stonith-1.x.x         libsnmp-0.4.2.6.so is needed by heartbeat-stonith-1.x.x 

Notice that the rpm command did not bother to report each of the GLIBC shared library package version numbers that are required—it only reported the highest numbered one that was required (GLIBC_2.3).[2] All of these failures are reporting the shared library names or sonames (not file names) that are required (sonames always start with "lib"). However, you can remove the version numbers tacked on to the end of the sonames reported by rpm and quickly check to see if you have these shared libraries installed on your system using the locate command.[3] For example, to look for the libcrypto shared library file you would enter:

 #locate libcrypto 

If this command does not find a libcrypto shared library file on your system, you'll have to go on the Internet and find out which shared library package contains this shared library file. One quick and easy way to do this is to simply enter the name of the shared library into the Google Linux search at http://www.google.com/linux. If you enter the text libcrypto.so into this search page, you'll quickly learn that this shared library is provided by the openssl package.

If an older version of the shared library package is already installed on your system, you can confirm that this package contains the shared library file you need with a command like this:

 #rpm -q --provides openssl 

This command reports everything this rpm package provides (which includes the sonames of the shared library files provided by the package).

Note 

As stated previously, the shared library package version numbers do not, and should not, have any correspondence to the shared library file (soname) version number. I've left out of this discussion the fact that a soname symbolic link may point to different versions of a shared library file. This is also done in an effort to avoid breaking existing dynamic executables when a new version of a shared library package is installed.

Fixing a Dependency Failure Automatically

Dependency failures can quickly turn into a nightmare when you work with rpm packages to build, upgrade, or add new features to your system. You can avoid this nightmare by simply using your distribution vendor's update service or tool. For example, the Red Hat utility up2date automatically downloads and installs any rpm dependencies directly from Red Hat when you select an rpm package to install. Several community-supported, free methods to accomplish the same thing are listed on the website http://www.rpm.org/software/updaters. In this appendix, we'll take a closer look at just one of these automatic update tools: Yum.

[2]The assumption is that the original package developer would not dynamically link executables within the same package to incompatible versions of a shared library package

[3]Assuming your locate database is up to date. See the man page for locate or slocate for more information.



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