Bug 694704
Summary: | 2 perl packages need to be debugged because of conflicting files | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Keith <moundie_from_wow> |
Component: | yum | Assignee: | Seth Vidal <skvidal> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 14 | CC: | chris.hembrow, cweyl, ffesti, iarnell, james.antill, kasal, lkundrak, maxamillion, mmaslano, pmatilai, ppisar, psabata, rc040203, tcallawa, tim.lauridsen |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-08-16 21:35:27 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: |
Description
Keith
2011-04-08 04:45:09 UTC
Updating for dependencies: [...] perl-version noarch 3:0.82-142.fc14 updates 51 k perl-version x86_64 3:0.88-1.fc14 updates 67 k This is nonsense as the packages have the same name and are not in multi-lib relation. That means one must supersede another and yum/rpm is expected to install perl-version-3:0.88-1.fc14.x86_64 and uninstall perl-version-3:0.82-142.fc14.noarch in one upgrade transaction. This really is nonsense. I suspect the "output from the console" has been "photoshopped". Notice here that "perl-version-3:0.88-1.fc14.x86_64" simply appears out of context in the middle of a line: > --> Processing Dependency: perl = 4:5.12.2-136.fc14 > fperl-version-3:0.88-1.fc14.x86_64or package: And again, "perl-version-3:0.88-1.fc14.x86_64" is just dumped in the middle of another message: > ---> Package perl-Test-Harness.noarch > 0:3.17-142.fc1perl-version-3:0.88-1.fc14.x86_644 set to be updated And while we're at it, when does yum ever use "n-e:v-r.a" format? (that sounds like repoquery). With yum, it's always "e:n-v-r.a" or "n.a e:v-r", isn't it? without wishing to cast aspersions, it also seems awfully convenient that this appears right after bug #633775 sprang up again after 10 weeks with no comment. I agree with you Iain. I've tested (again) update from noarch perl-version to arch version and yum can handle it. I suppose we can close it and don't drag more people into this. Keith: for such "jokes" were already bugzilla accounts closed. Wow. You people really are obnoxious. Just because you can't replicate something you consider it "a joke" or "photoshopped"?! I hope you're proud of yourselves. I had exactly the same error today trying to "yum install 389-ds" ; it failed due to the mismatch between "perl-version.noarch" and "perl-version.x86_64". Trying "yum update perl" also failed for the same reason. The only way I was able to get it to work was to explicitly update perl-version, which installed the x86_64 version instead of the noarch, and also updated perl. Then I was able to install 389-ds. There is obviously something amiss in the packaging that yum can't determine to replace the noarch with the arch version except as a direct update. I hope this helps someone else, even if you're not prepared to accept this as a legitimate bug. (In reply to comment #4) > Wow. You people really are obnoxious. Thanks! > Just because you can't replicate > something you consider it "a joke" or "photoshopped"?! I hope you're proud of > yourselves. No. I considered it to be "photoshopped" for the reasons I gave - the output presented simply wasn't credible. > I had exactly the same error today trying to "yum install 389-ds" ; it failed > due to the mismatch between "perl-version.noarch" and "perl-version.x86_64". > Trying "yum update perl" also failed for the same reason. The only way I was > able to get it to work was to explicitly update perl-version, which installed > the x86_64 version instead of the noarch, and also updated perl. Then I was > able to install 389-ds. This was enough to suggest a likely scenario, and without being distracted by incredible evidence, I gave it a shot: Start with a clean, minimal f14 installation with no updates. "yum --disablerepo updates install perl-version" and you get 3:perl-version-0.82-136.fc14.noarch installed (as you would have done prior to February when 3:perl-version-0.88-1.fc14.x86_64 was released). Then, you can run into difficulties when selectively updating/installing: # yum update perl Setting up Update Process Resolving Dependencies --> Running transaction check --> Processing Dependency: perl(threads::shared) for package: 4:perl-5.12.3-143.fc14.x86_64 --> Processing Dependency: perl(threads::shared) >= 1.21 for package: 4:perl-5.12.3-143.fc14.x86_64 --> Processing Dependency: perl = 4:5.12.2-136.fc14 for package: 1:perl-Module-Pluggable-3.90-136.fc14.noarch --> Processing Dependency: perl = 4:5.12.2-136.fc14 for package: 1:perl-Pod-Escapes-1.04-136.fc14.noarch --> Processing Dependency: perl = 4:5.12.2-136.fc14 for package: 4:perl-libs-5.12.2-136.fc14.x86_64 --> Processing Dependency: perl = 4:5.12.2-136.fc14 for package: 1:perl-Pod-Simple-3.13-136.fc14.noarch --> Processing Dependency: perl = 4:5.12.2-136.fc14 for package: 3:perl-version-0.82-136.fc14.noarch ---> Package perl.x86_64 4:5.12.3-143.fc14 set to be updated --> Running transaction check ---> Package perl-Module-Pluggable.noarch 1:3.90-143.fc14 set to be updated ---> Package perl-Pod-Escapes.noarch 1:1.04-143.fc14 set to be updated ---> Package perl-Pod-Simple.noarch 1:3.13-143.fc14 set to be updated ---> Package perl-libs.x86_64 4:5.12.3-143.fc14 set to be updated ---> Package perl-threads-shared.x86_64 0:1.32-143.fc14 set to be installed ---> Package perl-version.noarch 3:0.82-143.fc14 set to be updated ---> Package perl-version.x86_64 3:0.88-2.fc14 set to be updated --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: perl x86_64 4:5.12.3-143.fc14 updates 11 M Installing for dependencies: perl-threads-shared x86_64 1.32-143.fc14 updates 51 k Updating for dependencies: perl-Module-Pluggable noarch 1:3.90-143.fc14 updates 38 k perl-Pod-Escapes noarch 1:1.04-143.fc14 updates 31 k perl-Pod-Simple noarch 1:3.13-143.fc14 updates 211 k perl-libs x86_64 4:5.12.3-143.fc14 updates 594 k perl-version noarch 3:0.82-143.fc14 updates 51 k perl-version x86_64 3:0.88-2.fc14 updates 67 k Transaction Summary ================================================================================ Install 1 Package(s) Upgrade 7 Package(s) As you've found, though, the workaround is simply a matter of explicitly including perl-version in any yum update, or probably even better, simply run "yum update" to update everything rather than specific individual packages. > There is obviously something amiss in the packaging that yum can't determine to > replace the noarch with the arch version except as a direct update. I think the bug actually lies in yum thinking that it's okay to install both noarch and arch at the same time. And it seems to me that this has now been fixed with yum-3.2.29 in f15. At least, attempting to force the issue by running "yum install perl-version.x86_64 perl-version.noarch" now fails earlier on f15 with "Error: Protected multilib versions: 3:perl-version-0.82-157.fc15.noarch != 3:perl-version-0.88-3.fc15.x86_64"; on f14, the same command will also try to install both versions and fail later with file conflicts. > I hope this helps someone else, even if you're not prepared to accept this as a > legitimate bug. There really is a bug - but I'm not sure what we can do about it. If the problem lies with yum, then even releasing an updated version of yum for f14 won't help unless you actually install it before trying to selectively update perl or install something that's going to pull in newer perl-version. (Maybe explicitly obsoleting or conflicting "perl-version < 3:0.88-2.fc14" in the arch package will help. Will try it and see). And finally, apologies to Keith. I guess I should eat my words and accept that your misleading output was nothing more than a simple copy/paste mix up rather than a deliberate attempt to deceive. This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |