Description of problem: Due to the recent firefox errata and bug 455845 and bug 455803, the released version of nspluginwrapper has a requirement on the old firefox. (Specifically gecko-libs=1.9 while the version provided by the new firefox is gecko-libs=1.9.0.1) yum realises that it can't use the xulrunner that its about to upgrade to resolve this, so ends up trying to resolve it via the older i386 firefox3.0 stack. While this does technically meet the requirements, it seems a bit silly, especially since a subsequent yum upgrade will then presumably fail for the other arch yum debug log attached. Version-Release number of selected component (if applicable): yum-3.2.16-2.fc9.noarch yum-3.2.17-2.fc9.noarch (from updates-testing) How reproducible: Always Steps to Reproduce: 1. Make sure that bug 455845 and bug 455803 aren't fixed 2. yum update xulrunner Actual results: Tries to install xulrunner-1.9-0.60.beta5.fc9.i386 Expected results: Gives an error Additional info: Yum should ignore non-latest packages when satisfying dependencies. I can see a case for allowing an older version to be chosen to work around other types of dependency breakage (or possibly a valid choice for singlearch->multiarch packages??), but the situation here just seems too weird to be valid.
Created attachment 312130 [details] yum -d 5 update
Sorry, this isn't a bug or a feature we're likely to implement. Yum is doing precisely what it is supposed to do. If this situation is untenable then the correct course of action is to fix your deps and/or the repositories. Adding code like this to yum just complicates the dep solving code more than necessary.