This was observed on FC6. The concern is that it may persist in FC7. Scenario: a package foo3-0.1 is installed. The user is out of date. The repository contains: foo3-0.2, the obvious update but also foo4-0.1 which claims to obsolete foo3 entirely. When yum attempts to process this update, it concludes that foo3-0.2 replaces foo3-0.1, but it also (wrongly) concludes that foo4-0.1 replaces foo3-0.1. That is, it is mishandling the obsolete processing. Output appears at the URL given. It is possible that I got the obsoletes line wrong in my coyotos-gcc4 package, but upgrades on other systems (ones that had been up to date on coyotos-gcc3) proceeded as expected. I marked this "high" because once you get here you can't get out of this corner without hand intervention. If you disagree about the priority assessment, then of course feel free to re-grade it. shap
I'm confused - does foo4 obsolete foo3 or not? If foo4 claims to obsolete it then yes, obsoletes are considered before updates are considered. So when running an update transaction the obsolete will be installed. I'm going to need more information on what the obsoletes line was and what packages were installed to understand if this is a bug at all.
That is what is *supposed* to happen, but it isn't happening. I can attach the spec files, but let me see if I can make this concrete. The master package emits nothing. Everything ends up in a subpackage. The old spec file (foo3 above), for example, has a subpackage Name: coyotos-i386-gcc3-gcc The new subpackage (foo4) name is declared in the spec file as: Name: coyotos-i386-gcc4-gcc The new package spec file also contains the lines: Obsoletes: coyotos-i386-gcc3 Autoreq: true The user had an old version of coyotos-i386-gcc3, and yum tried to give them both the new gcc3 and the update to gcc4. I did just notice one inconsistency in the spec file. I don't know if this is significant. I wrote above that all of the subpackages had Autoreq: true. I have just noticed that one of the subpackages is missing the Autoreq line. If this could be the source of the problem I can fix it and re-test. However, there are several subpackages following the same upgrade pattern, and I got this on a number of those. Perhaps that may have arisen from dependencies driven by the missing autoreq. If the autoreq is the probable cause, please let me know, but let's keep this open until I can rebuild and confirm. If it's "user error", I can live with that and I will gratefully apologize for wasting your time. Also, let me know if you want the old and new complete spec files attached.
Closing due to inactivity. Please reopen or file a new bug if you have further information to add to this bug report