Bug 824305
Summary: | Dependency glibc-common%{?_isa} should be changed to glibc-common only | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alen Siljak <alen.siljak> | ||||
Component: | redhat-lsb | Assignee: | Parag Nemade <pnemade> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | rawhide | CC: | ffesti, hliu, itsjustarumour.tech, ja, llim, maxamillion, misek, packaging-team, pmatilai, pnemade, tim.lauridsen, zpavlas | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-06-15 00:34:17 UTC | Type: | Bug | ||||
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
Alen Siljak
2012-05-23 08:47:34 UTC
Transaction Check Error: file /usr/bin/ldd from install of glibc-common-2.15-37.fc17.i686 conflicts with file from package glibc-common-2.15-37.fc17.x86_64 file /usr/lib/locale/locale-archive.tmpl from install of glibc-common-2.15-37.fc17.i686 conflicts with file from package glibc-common-2.15-37.fc17.x86_64 At least one of the issues here is that there shouldn't be a i686 version of glibc-common in the x86_64 repositories at all, it's not (and does not need to be) parallel-installable. The other question is, why is yum trying to install it at all? Please attach the entire output of 'yum -d5 update' for a better view of what's going on. Created attachment 586305 [details]
yum -d5 update
As requested, attached is the output of 'yum -d5 update'.
I've attached the output. The reason glibc.i686 is installed is that it is required by some 32-bit apps. Not sure whether it was Skype, Google Earth, or just Wine.i686 but some of these required it. Now, why is there glibc-common.i686, I can't really say. Hopefully the provided output will shed some more light. I tried to remove and reinstall i686 glibc but there are too many dependencies so I'll try to find another way. OK, found it: yum remove redhat-lsb.i686 and after that the update worked! Thanks for the tip. Nothing wrong with having glibc.i686 installed, its there for the very reason of being able to run 32bit software. glibc-common is a different kind of beast, and like its name says its supposed to be *common* for the arch variants. Thanks for the debug output, here's the problem: looking for ('glibc-common(x86-32)', None, (None, None, None)) as a requirement of redhat-lsb-core.i686 0:4.1-2.fc17 - u This is a packaging bug in redhat-lsb, %{?_isa} should not be used for glibc-common dependencies. Just out of curiosity - how do the results of your troubleshooting end up at the right address, i.e. someone who can fix this in redhat-lsb package? Thanks for your help. I'm glad that the updates are again flowing through for me. (In reply to comment #7) > Just out of curiosity - how do the results of your troubleshooting end up at > the right address, i.e. someone who can fix this in redhat-lsb package? By reassigning to the bug to the troublesome component (redhat-lsb in this case), which I did along with the previous comment :) (In reply to comment #6) > Nothing wrong with having glibc.i686 installed, its there for the very > reason of being able to run 32bit software. glibc-common is a different kind > of beast, and like its name says its supposed to be *common* for the arch > variants. > If its common for the arch variants then it should be noarch then right? I think glibc-common should be splitted into 2 packages, one that only installs locale files, charmaps and translations. Other package can be pure arch specific. BTW, What should be changed in redhat-lsb.spec? Requires: glibc-common%{?_isa} to Requires: glibc-common Alen, from where can I get google-chrome-unstable package? Hi Parag. I'm using the following repo locations: [google-chrome] name=google-chrome baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64 enabled=1 gpgcheck=1 and, just FYI: [google-earth] name=google-earth baseurl=http://dl.google.com/linux/earth/rpm/stable/x86_64 enabled=1 gpgcheck=1 (In reply to comment #9) > If its common for the arch variants then it should be noarch then right? I > think glibc-common should be splitted into 2 packages, one that only > installs locale files, charmaps and translations. Other package can be pure > arch specific. Splitting it to further doesn't really achieve anything IMO, the point is that glibc-common is not a multilib package. It contains arch-specific binaries for the primary arch (whatever it is) and should not even be available as a secondary arch package. Just like eg 'bash' only exists in one arch variant, anything else just wouldn't make sense. > BTW, What should be changed in redhat-lsb.spec? > Requires: glibc-common%{?_isa} > to > Requires: glibc-common Yes. And FWIW, you dont need google-chrome-unstable for "reproducing" this, just try to install redhat-lsb-core.x86_64 and redhat-lsb-core.i686 simultaneously. Some more FYI. I have found the culprit. As per the following article: http://fooninja.net/2011/01/25/google-earth-in-64-bit-linux-fedora-ubuntu/ I've installed redhat-lsb.i686 package in the past in order to run google-earth. For those affected by this update, here is as old bug report that also contains a workaround: https://bugzilla.redhat.com/show_bug.cgi?id=477956 The command "ln -s ld-linux.so.2 ld-lsb.so.3" will create a symlink on 64-bit OS and Google Earth will work just fine. No need to install redhat-lsb.i686. redhat-lsb-4.1-4.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/redhat-lsb-4.1-4.fc17 Package redhat-lsb-4.1-4.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing redhat-lsb-4.1-4.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-8633/redhat-lsb-4.1-4.fc17 then log in and leave karma (feedback). redhat-lsb-4.1-4.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. I assume I am missing something obvious !? yum update gives Error: Protected multilib versions: redhat-lsb-4.1-4.fc17.x86_64 != redhat-lsb-4.0-11.fc17.i686 [root@avon ~]# rpm -qa|grep redhat-lsb redhat-lsb-4.0-11.fc17.x86_64 redhat-lsb-4.0-11.fc17.i686 [root@avon ~]# yum update Loaded plugins: langpacks, presto, refresh-packagekit, stablemirror stablemirror: the easily edited stablemirror file is "/var/cache/yum/stablemirrors" local-17-update | 2.9 kB 00:00 ... updates-master | 4.5 kB 00:00 adobe-linux-i386 | 951 B 00:00 adobe-linux-x86_64 | 951 B 00:00 google-chrome | 951 B 00:00 google-earth | 951 B 00:00 rpmfusion-free-updates | 3.3 kB 00:00 rpmfusion-nonfree-updates | 3.3 kB 00:00 updates/metalink | 17 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package redhat-lsb.x86_64 0:4.0-11.fc17 will be updated ---> Package redhat-lsb.x86_64 0:4.1-4.fc17 will be an update --> Processing Dependency: redhat-lsb-printing = 4.1 for package: redhat-lsb-4.1-4.fc17.x86_64 --> Processing Dependency: redhat-lsb-languages = 4.1 for package: redhat-lsb-4.1-4.fc17.x86_64 --> Processing Dependency: redhat-lsb-desktop(x86-64) = 4.1 for package: redhat-lsb-4.1-4.fc17.x86_64 --> Processing Dependency: redhat-lsb-cxx(x86-64) = 4.1 for package: redhat-lsb-4.1-4.fc17.x86_64 --> Processing Dependency: redhat-lsb-core(x86-64) = 4.1 for package: redhat-lsb-4.1-4.fc17.x86_64 --> Running transaction check ---> Package redhat-lsb-core.x86_64 0:4.1-4.fc17 will be installed --> Processing Dependency: redhat-lsb-submod-security(x86-64) = 4.1 for package: redhat-lsb-core-4.1-4.fc17.x86_64 ---> Package redhat-lsb-cxx.x86_64 0:4.1-4.fc17 will be installed ---> Package redhat-lsb-desktop.x86_64 0:4.1-4.fc17 will be installed --> Processing Dependency: redhat-lsb-submod-multimedia(x86-64) = 4.1 for package: redhat-lsb-desktop-4.1-4.fc17.x86_64 --> Processing Dependency: libpng12.so.0()(64bit) for package: redhat-lsb-desktop-4.1-4.fc17.x86_64 ---> Package redhat-lsb-languages.x86_64 0:4.1-4.fc17 will be installed --> Processing Dependency: perl(Test::Simple) for package: redhat-lsb-languages-4.1-4.fc17.x86_64 --> Processing Dependency: perl(Pod::Plainer) for package: redhat-lsb-languages-4.1-4.fc17.x86_64 ---> Package redhat-lsb-printing.x86_64 0:4.1-4.fc17 will be installed --> Running transaction check ---> Package libpng-compat.x86_64 2:1.5.10-1.fc17 will be installed ---> Package perl-Pod-Plainer.noarch 0:1.03-1.fc17 will be installed ---> Package perl-Test-Simple.noarch 0:0.98-211.fc17 will be installed ---> Package redhat-lsb-submod-multimedia.x86_64 0:4.1-4.fc17 will be installed ---> Package redhat-lsb-submod-security.x86_64 0:4.1-4.fc17 will be installed --> Finished Dependency Resolution Error: Protected multilib versions: redhat-lsb-4.1-4.fc17.x86_64 != redhat-lsb-4.0-11.fc17.i686 [root@avon ~]# Purely a repo problem Sorry for the noise John |