Bug 253624

Summary:	Yum update fails with obsolete
Product:	[Fedora] Fedora	Reporter:	Jonathan S. Shapiro <shap>
Component:	yum	Assignee:	Jeremy Katz <katzj>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	high
Version:	6	CC:	james.antill
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
URL:	http://www.coyotos.org/pipermail/coyotos-dev/2007-August/001119.html
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-12-31 14:54:27 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jonathan S. Shapiro 2007-08-20 21:52:47 UTC

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

Comment 1 Seth Vidal 2007-08-21 04:43:07 UTC

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.

Comment 2 Jonathan S. Shapiro 2007-08-28 03:24:15 UTC

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.

Comment 3 Jeremy Katz 2007-12-31 14:54:27 UTC

Closing due to inactivity.  Please reopen or file a new bug if you have further
information to add to this bug report