From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6
Description of problem:
When yum reports a dependency conflict and the archs for the conflicting packages differ, it should list the archs of the conflicting packages. I think this arises when there are non-exact version matches for multi-lib support of i386 and x86_64. The present error is quite obscure, and requires either experience or asking someone what it means.
This RFE is prompted by the fedora-list thread "More and more yum depandency problems" at Message-ID: <42EF3A85.firstname.lastname@example.org>. I'm not using x64 or FC4 myself (yet), but having this feature would benefit me when I do, and would benefit others now. The actual problem might be with RPM for all I know.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.roughly, have an x64 system
2.using multi-lib support, install i386 and x86_64 versions of same package
3.manage to get versions out of sync somehow
Actual Results: confusing error message about having two of a package installed.
Expected Results: less confusing message listing arch of each conflicting package, as part of package name and version.
Seth -- what do you think about changing everything that prints out a package
name to be name.arch? I think we probably also want to move this to be part of
the default rpm query output
in lots of cases we don't have that info being handed back from rpm.
and if we change it in the default rpmq you better announce it heavily b/c it
will break A LOT of scripts.
The arch info is only needed when there are conflicts already found. Could RPM
be queried a second time in such cases? Then there would be no need to change
any default queries, only to add a new query.
The problem is we can't know what it is.
if I get back foo-1.1-1 from rpm
and we have foo-1.1-1.i386 and foo-1.1-1.x86_64 installed yum has no way of
knowing which it was asking about.
it has to guess.
Then if yum can't do any better, it should query RPM to find if there are
potential arch conflicts and if so tell the user that the conflict may stem from
conflicts aren't arch-specific.
Right, when you get a conflict you have to find out more about it to be useful
to the user. Query RPM to find out if the conflict /could/ be from multiple
archs, if you can't find out if it /is/. Give the user a clue to work with.
When a conflict is reported by RPM, get more info about the installed versions
of packages from RPM, including their arch. If the conflicting packages come in
different archs, tell the user it may be an arch conflict for those packages.