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.3040406.at>. 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): How reproducible: Didn't try 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. Additional info:
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 incompatible archs.
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.