Hide Forgot
Description of problem: When dependency solving fails due to mismatch in .so version (for instance, the version required is less than the version installed or available) then the error message says only that the required version is "Not found", and does not say that the greater version is installed or available. Omitting this relevant information often confuses the user. Instead, the message _also_ should list the installed/available versions. Version-Release number of selected component (if applicable): yum-3.4.3-3.fc16.noarch How reproducible: every time (3 times so far) Steps to Reproduce: 1. yum localupdate parted-3.0-2.fc16.x86_64.rpm 2. 3. Actual results: Error: Package: gparted-0.8.1-1.fc16.x86_64 (@rawhide/15) Requires: libparted.so.0()(64bit) Removing: parted-2.4-2.fc16.x86_64 (@rawhide/15) libparted.so.0()(64bit) Updated By: parted-3.0-2.fc16.x86_64 (/parted-3.0-2.fc16.x86_64) Not found Expected results: Append "Versions available are: libparted.so.1()(64bit) from parted-3.0-2.fc16.x86_64" to the "Not found". Additional info: # rpm -q --provides -p parted-3.0-2.fc16.x86_64.rpm libparted.so.1()(64bit) ### Note version .1 instead of .0 parted = 3.0-2.fc16 parted(x86-64) = 3.0-2.fc16
The problem is that there's no way to go from "libparted.so.0()(64bit)" to "libparted.so.1()(64bit)" ... they are just strings like "foo" and "bar". In theory we could try pattern matching, but I'm not sure if that would be a good idea.
Yeh, taking a look we'd need to change a lot of code here ... as atm. we are just looking for the specific provide name, so we'd have to change to start walking all provides and fuzzy matching them to the missing provide. I'll leave it open for a bit though.
(In reply to comment #1) > The problem is that there's no way to go from "libparted.so.0()(64bit)" to > "libparted.so.1()(64bit)" ... they are just strings like "foo" and "bar". The major use case of designating shared libraries (and their versions and flavors) should be supported directly, not as "just strings". > In theory we could try pattern matching, but I'm not sure if that would be a > good idea. As long as "just strings" then align them vertically when printing, so that columnar comparison "by eyeball" is easier: requires: <the requirement string> by <requiring package name> available: <the available string> in <supplying package name> For pattern matching, I suggest that a match of the first six characters of two strings should be enough to consider them as related. Also, sort the rows alphabetically when printing.
Added a fix upstream: commit a3c07d85f045cee868a78405ffdd6e537158a99a Author: James Antill <james> Date: Tue May 28 16:28:29 2013 -0400 Add a fuzzy matcher for numbers in format_missing_requires. BZ 718245. ...Eg. Error: Package: compiz-gtk-0.9.5.92.1-0.2.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc16.x86_64 (@updates/16) Requires: libboost_serialization-mt.so.1.47.0()(64bit) Removing: boost-serialization-1.47.0-7.fc16.x86_64 (@updates/16) libboost_serialization-mt.so.1.47.0()(64bit) Updated By: boost-serialization-1.50.0-5.fc18.x86_64 (updates) ~libboost_serialization-mt.so.1.50.0()(64bit)
yum and related packages are no longer actively developed. They are being replaced with dnf, dnf-utils, etc. I'm closing this bug because it's most likely never going to be fixed. If you still consider your bug report important, reopen it, please.