Red Hat Bugzilla – Bug 253624
Yum update fails with obsolete
Last modified: 2014-01-21 17:59:02 EST
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
foo3-0.2, the obvious update
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.
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
The new subpackage (foo4) name is declared in the spec file as:
The new package spec file also contains the lines:
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