Bug 600969

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.