Red Hat Bugzilla – Bug 460783
yum install <virtual-provides>, installs different package names on multiarch
Last modified: 2014-01-21 18:06:11 EST
yum 3.2.19-1.fc9 in F-9, x86_64, no packages providing java-devel installed:
# yum install java-devel
java-1.5.0-gcj-devel x86_64 18.104.22.168-21.fc9 fedora 46 k
java-1.6.0-openjdk-devel i386 1:22.214.171.124-0.16.b09.fc9 updates 9.0 M
Installing for dependencies:
- Should not install two packages.
- i386 version of java-1.6.0-openjdk-devel installed instead of x86_64.
I think the correct behavior would be to get only java-1.6.0-openjdk-devel.x86_64 (not i386). Until bug 460781 is resolved, I'd understand getting either java-1.5.0-gcj-devel.x86_64 or java-1.6.0-openjdk-devel.x86_64, but not both.
Forgot to mention that this together with bug 460761 can cause bad builds (eg. i386 code compiled into x86_64 packages on x86_64) that go unnoticed, or if we're fortunate and these packages have test suites, build failures.
Bumping priority/severity accordingly. Also happens in mock buildroots for current Rawhide x86_64.
On a 2nd thought, I'm not 100% sure if this issue can result in i386 code built into x86_64 packages. But test suite failures do happen.
Can you attach a full "-d 9" of the yum install.
Created attachment 315767 [details]
yum -d 9 --disablerepo="*" --enablerepo=fedora --enablerepo=updates install java-devel
Just to try it out, I also tried with --disableplugin="*", but it did not make a difference.
Do you have multilib_policy=all ?
The trace shows:
Potential match for java-devel from java-1.5.0-gcj-devel-126.96.36.199-21.fc9.x86_64
Matched java-1.5.0-gcj-devel-188.8.131.52-21.fc9.x86_64 to require for java-devel
Potential match for java-devel from 1:java-1.6.0-openjdk-devel-184.108.40.206-0.10.b09.fc9.x86_64
Matched 1:java-1.6.0-openjdk-devel-220.127.116.11-0.10.b09.fc9.x86_64 to require for java-devel
Potential match for java-devel from 1:java-1.6.0-openjdk-devel-18.104.22.168-0.10.b09.fc9.i386
Matched 1:java-1.6.0-openjdk-devel-22.214.171.124-0.10.b09.fc9.i386 to require for java-devel
Potential match for java-devel from 1:java-1.6.0-openjdk-devel-126.96.36.199-0.16.b09.fc9.i386
Matched 1:java-1.6.0-openjdk-devel-188.8.131.52-0.16.b09.fc9.i386 to require for java-devel
Potential match for java-devel from 1:java-1.6.0-openjdk-devel-184.108.40.206-0.16.b09.fc9.x86_64
Matched 1:java-1.6.0-openjdk-devel-220.127.116.11-0.16.b09.fc9.x86_64 to require for java-devel
---> Package java-1.5.0-gcj-devel.x86_64 0:18.104.22.168-21.fc9 set to be updated
---> Package java-1.6.0-openjdk-devel.i386 1:22.214.171.124-0.16.b09.fc9 set to be updated
...I'm not 100% sure this is really a bug (ask to install a provides with multilib_policy=all, and you get two packages as each one only provides half of the arch).
Actualy, openjdk provides both arches ... just that gcj is considered "better", so we take that for the arches it's on. Maybe we want to change that so it'll just pick openjdk. Of course then people get a different .x86_64 package depending on what they have for multilib_policy ... which seems too magic.
I have multilib_policy=best.
Ok, I've just tried it using just:
yum remove java-devel
yum install java-devel
...what happens is:
# Try package name match:
parsePackages() = no matches
# So try dep match:
returnPackagesByDep() = all versions/arches of gcj and openjdk
bestPackagesFromList() = latest version, best arch, for each package
later code treats packages with different names as different, as they might have come from a wildcard match.
...so I've fixed bestPackageFromList to only return a single package, in the dep. case. upstream commit: 8732871e2946b1cf5237cf1b2ed7517d4fa5261c.
The current behaviour is to just drop the .i386 pacakge, which I think is the right thing to do.
Of course I screwed it up at the last minute so you need upstream commit: 2a08589d63a21af98c533fe0c6e37e298617e5bd as well.
The patches seem to work, now only java-1.5.0-gcj-devel.x86_64 is installed, thanks. I find it unfortunate that it does not pick java-1.6.0-openjdk-devel.x86_64 instead but we've discussed that in another bug.
this is fixed upstream and it is available in a current release of yum.