Description of problem: Lets assume I have a package that requires foo and want to install it. If there are two (or more) packages that provide foo, neither of them installed, yum selects one of them and adds it to the installation set. But, if the other package is already selected (through some other symbol it provides), yum wants to install both of them. Version-Release number of selected component (if applicable): yum-3.4.3-5.fc16.noarch How reproducible: always Steps to Reproduce: 1. get the attached spec files 2. build the rpms 3. put the rpms to a dir, say, /tmp/yumtest 4. createrepo /tmp/yumtest 5. put the attached yumtest.repo to /etc/yum.repos.d 6. yum install c Actual results: a, b and c are selected for installation. Expected results: Just a and c are selected for installation.
Created attachment 530266 [details] a.spec
Created attachment 530267 [details] b.spec
Created attachment 530268 [details] c.spec
Created attachment 530269 [details] repo config.
Can you provide the output, as I'd assume what's happening is that it's resolving "requires: foo" first, and choosing b ... as I'm pretty sure it'll do the right thing if it resolves a first (Eg. yum install a c).
Created attachment 530425 [details] yum install --debuglevel=10 c
Yeh, as I thought: c-1-1.fc16.noarch requires: foo --> Processing Dependency: foo for package: c-1-1.fc16.noarch [...] TSINFO: Marking b-1-1.fc16.noarch as install for c-1-1.fc16.noarch c-1-1.fc16.noarch requires: a --> Processing Dependency: a for package: c-1-1.fc16.noarch ...there are some tricks you can use to have the specific requirment run first (Eg. yum will prefer versioned requires, and prefers them in this order: =, <, <=, >, >=). But atm. we can't easily make it go back and make a different choice.
(In reply to comment #7) > Yeh, as I thought: > > c-1-1.fc16.noarch requires: foo > --> Processing Dependency: foo for package: c-1-1.fc16.noarch > [...] > TSINFO: Marking b-1-1.fc16.noarch as install for c-1-1.fc16.noarch > > c-1-1.fc16.noarch requires: a > --> Processing Dependency: a for package: c-1-1.fc16.noarch > > ...there are some tricks you can use to have the specific requirment run first > (Eg. yum will prefer versioned requires, and prefers them in this order: =, <, > <=, >, >=). But atm. we can't easily make it go back and make a different > choice. I can do that for explicit dependencies, but not for generated ones. My use case is bug 748585, where (generated) dependency on libjawt.so()(...) in libreoffice-core selects java-1.7.0-openjdk and (explicit) dependency on jre >= 1.5.0 in libreoffice-ure selects java-1.6.0-openjdk.