Bug 600969 - yum localupdate doesn't process obsoletes
Summary: yum localupdate doesn't process obsoletes
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-06 20:55 UTC by Didier G
Modified: 2014-01-21 23:15 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2011-06-27 17:40:40 UTC

Attachments (Terms of Use)
llvm_update_with_yum (7.02 KB, application/octet-stream)
2010-06-07 00:36 UTC, Didier G
no flags Details

Description Didier G 2010-06-06 20:55:21 UTC
Description of problem:

yum request i686 dependencies to install llvm x86-64 updates

Version-Release number of selected component (if applicable):


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

Comment 1 James Antill 2010-06-07 00:00:17 UTC
There is no attachment.

Comment 2 Didier G 2010-06-07 00:36:04 UTC
Created attachment 421686 [details]

Comment 3 James Antill 2010-06-07 03:28:24 UTC
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.

Comment 4 Michel Alexandre Salim 2010-06-07 08:46:50 UTC
*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.

Comment 5 James Antill 2010-06-07 13:29:39 UTC
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 :(.

Comment 6 Michel Alexandre Salim 2010-06-07 13:36:51 UTC
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.

Comment 7 Michel Alexandre Salim 2010-06-08 07:23:18 UTC
(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 :(.    


Unfortunately, that does not work. Please try the llvm-2.7-5 scratch builds here:

where llvm-doc Obsoletes: llvm-doc < %{version}-%{release}


- 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.

Comment 8 Michel Alexandre Salim 2010-06-08 08:11:26 UTC

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

Comment 9 James Antill 2010-06-08 14:13:43 UTC
 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
 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
 llvm-doc        noarch        2.7-5.fc13          T-Down-4c0e4f87        760 k
     replacing  llvm-doc.x86_64 2.7-1.fc13
 llvm            x86_64        2.7-5.fc13          T-Down-4c0e4f87        6.5 M

Comment 10 James Antill 2010-06-08 15:20:26 UTC
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):
             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:

...should be in 3.2.28, just use --tmprepo or the koji repo. until then.

Comment 11 Michel Alexandre Salim 2010-06-09 18:14:39 UTC
Thanks, James. I'll push the LLVM updates, then.

Comment 12 Bug Zapper 2011-06-02 11:47:36 UTC
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: 

Comment 13 Bug Zapper 2011-06-27 17:40:40 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.