Bug 455860

Summary: Dependancy resolution picks older package from other arch
Product: [Fedora] Fedora Reporter: Bradley <bbaetz>
Component: yumAssignee: Seth Vidal <skvidal>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: ffesti, james.antill, katzj, pmatilai, tim.lauridsen
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-18 13:25:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
yum -d 5 update none

Description Bradley 2008-07-18 12:51:19 UTC 
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.
Comment 1 Bradley 2008-07-18 12:51:19 UTC 
Created attachment 312130 [details]
yum -d 5 update
Comment 2 Seth Vidal 2008-07-18 13:25:13 UTC 
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.