Description of problem: yum request i686 dependencies to install llvm x86-64 updates Version-Release number of selected component (if applicable): yum-3.2.27-4.fc13.noarch How reproducible: - after download of 2.7-4 from koji, when I tried to install the 3 updates with *** yum localupdate ***, I got messages to request install of additional i686 packages - I replied *** No *** so I did not install updates and additional i686 packages - I tried to install the 3 update packages with *** rpm -Uvh *** and I did not need any additional i686 packages so I installed the 3 updates Additional info: See attached log file
There is no attachment.
Created attachment 421686 [details] llvm_update_with_yum
The problem is that you did an update, and the new llvm-docs is a different arch from the old llvm-docs ... and there is no obsoletes. And llvm-docs has a requirement on llvm of the same version. yum tried to solve this problem by installing the available .i686 version of llvm. Not sure what rpm did, it's very possible you have both the old and new packages installed now. Feel free to run "yum check", although yum will see rpm did something behind it's back and force run it for you the next time you run a transaction with yum.
*Ah* thanks. Is the solution in this case to make the (arch-specific) main llvm package Obsoletes: the old llvm-doc? In that case, I'll issue a new set of LLVM packages.
In llvm-doc you want a versioned obsolete, as you switch from the arch version to the noarch version. No need to involve the main "llvm" package. I thought this was documented on the wiki, but I can't see it under the noarch sub-package page :(.
I thought it would be on the wiki too, but as you said, it's not :(. It's not on the announcement (on rpm-announce) for noarch subpackages either. Should we bring this up in fedora-packaging? Sounds like something that could bite a lot of developers, since there remains many packages with arch-specific documentation subpackages that could be converted.
(In reply to comment #5) > In llvm-doc you want a versioned obsolete, as you switch from the arch version > to the noarch version. No need to involve the main "llvm" package. > > I thought this was documented on the wiki, but I can't see it under the noarch > sub-package page :(. James, Unfortunately, that does not work. Please try the llvm-2.7-5 scratch builds here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2236690 where llvm-doc Obsoletes: llvm-doc < %{version}-%{release} Observations: - yum localupdate llvm{,-devel,-doc}-*.rpm does not pull in llvm-doc at all - yum localinstall of the same packages does not either In both cases, yum noticed the -doc package: Examining llvm-doc-2.7-5.fc13.noarch.rpm: llvm-doc-2.7-5.fc13.noarch Marking llvm-doc-2.7-5.fc13.noarch.rpm as an update to llvm-doc-2.7-1.fc13.x86_64 and then failed to mention it in the list of packages to be actioned upon - llvm.i686 is still pulled in as a dependency of llvm-doc-2.7-1 So it looks like a way to make the update works is to add some fake Provides: / Obsoletes: in the *main* package (because then the arch will match the arch in the old -doc subpackage), but it's a rather ugly solution. Drawback: installing llvm-doc would be self-satisfied by llvm itself, therefore the -doc can no longer be installed. This does actually seem like a bug. RPM handles the arch->noarch conversion gracefully so I'm inclined to think it's a yum bug right now.
Addendum: I first thought that adding Obsoletes: %{name}-doc < %{version}-%{release} is not enough, and added a matching Provides: %{name}-doc = %{version}-%{release} line. This, as it turns out, is redundant -- Provides: metadata are not arch-specific anyway: $ rpm -qp --provides ~/Downloads/llvm-doc-2.7-5.fc13.noarch.rpm llvm-doc = 2.7-5.fc13 llvm-doc = 2.7-5.fc13 ^ \--- one of these manually added, one generated by RPM from the N-V-R
This is a bug in the localupdate path. As you say I get: Examining /home/james/Downloads/llvm-doc-2.7-5.fc13.noarch.rpm: llvm-doc-2.7-5.fc13.noarch Marking /home/james/Downloads/llvm-doc-2.7-5.fc13.noarch.rpm as an update to llvm-doc-2.7-1.fc13.x86_64 [...] Updating: llvm x86_64 2.7-5.fc13 /llvm-2.7-5.fc13.x86_64 21 M Installing for dependencies: llvm i686 2.7-1.fc13 updates 6.2 M ...but if I do: % yum update llvm\* --tmprepo=/home/james/Downloads [...] Installing: llvm-doc noarch 2.7-5.fc13 T-Down-4c0e4f87 760 k replacing llvm-doc.x86_64 2.7-1.fc13 Updating: llvm x86_64 2.7-5.fc13 T-Down-4c0e4f87 6.5 M
This patch should solve it: --- a/yum/__init__.py +++ b/yum/__init__.py @@ -3490,8 +3490,8 @@ class YumBase(depsolve.Depsolve): for obsoleting_pkg in packagesNewestByName(obs_pkgs): tx_return.extend(self.install(po=obsoleting_pkg)) for available_pkg in availpkgs: - for obsoleted in self.up.obsoleting_dict.get(available_pkg.pkgt - obsoleted_pkg = self.getInstalledPackageObject(obsoleted) + for obsoleted_pkg in self._find_obsoletees(available_pkg): + obsoleted = obsoleted_pkg.pkgtup txmbr = self.tsInfo.addObsoleting(available_pkg, obsoleted_ if requiringPo: txmbr.setAsDep(requiringPo) ...should be in 3.2.28, just use --tmprepo or the koji repo. until then.
Thanks, James. I'll push the LLVM updates, then.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.