On 18/03/07, Chris Mohler wrote:
Have you "cleaned out" yum? # yum clean all && yum update Have you tried rebuilding the rpm db? # rm -f /var/lib/rpm/__db* # rpm -vv --rebuilddb I've never had a problem rebuilding, but some have suggested making a backup of /var/lib/rpm before doing so - if you have the disk space it wouldn't hurt ;)
In either case, prior to "yum update", querying the installed device-mapper should list the needed items. Run: rpm --query --provides device-mapper This is a prerequisite to finding out why libdevmapper.so.1.02 is not seen. Additionally, since remote trouble-shooting is less fast and less convienient, perhaps you can "yum install yum-utils" and then run repoquery --whatprovides libdevmapper.so.1.02 at least that should return something.
Those are the first two steps I take when yum/rpm start acting wierd. Most of the dep problems I've had come from mixing repos, and can be solved by temporarly removing packages and adding them back later. Good luck!
A hard problem -- for anyone who doesn't want to deal with package dependencies at all -- with mixing repos is that one of the packages _to be installed_ (!) takes away or replaces what was available before a yum update and thereby breaks dependencies for the new packages or old ones which are installed already. This is terribly confusing when the user examines the installed packages and sees that a certain library version is available, but yum complains about it as missing when it fails to do the update. It doesn't become obvious that one of the new packages to be installed is the culprit. This is not the case here, but with other repos in the mix it is possible that something upgrades device-mapper to libdevmapper.so.1.03 or a different version and thereby takes away the needed 1.02 version.
