Bug 527432

Summary: Yum can not handle correctly obsolete of obsolete in one transaction
Product: Red Hat Enterprise Linux 5 Reporter: Miroslav Suchý <msuchy>
Component: yumAssignee: packaging-team-maint
Status: CLOSED CURRENTRELEASE QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: low    
Version: 5.4CC: james.antill, sgraf
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-30 05:00:47 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Miroslav Suchý 2009-10-06 08:12:02 EDT
Description of problem:
During preparation of RHBA-2009:8906-02 I find that yum could not correctly handle following situation:
We start with package 
 rhn-ssl-cert-check-1.4-10.7.el5.noarch
which is quite normal.
Then we have package :
 spacewalk-ssl-cert-check.noarch 1.7-1.el5sat
with following obsoletes and provides:
 Obsoletes: rhn-ssl-cert-check < %{version}
 Provides:  rhn-ssl-cert-check = %{version}

And finally package:
 rhn-ssl-cert-check-5.2-1.1.el5:1.noarch
with following obsoletes and provides:
 Obsoletes: spacewalk-ssl-cert-check < 1.8
 Provides:  spacewalk-ssl-cert-check = 1.8

Now let assume I have rhn-ssl-cert-check-1.4-10.7.el5.noarch installed.

If I have rhn-ssl-cert-check-1.4-10.7.el5.noarch and rhn-ssl-cert-check-5.2-1.1.el5:1.noarch in one repo, then yum upgrade correctly.
If I have rhn-ssl-cert-check-1.4-10.7.el5.noarch and spacewalk-ssl-cert-check.noarch 1.7-1.el5sat in one repo, then yum upgrade correctly.
BUT, if I have all three packages in one repo, then when I run "yum upgrade" yum will upgrade to spacewalk-ssl-cert-check. And if I immediately (i.e. no changes neither in repo nor on system) "yum upgrade" yum will upgrade to 
rhn-ssl-cert-check-5.2-1.1.el5:1.noarch.
I would assume that correct way is direct upgrade.

If I create package:
rhn-ssl-cert-check-5.2-1.1.el5:1.noarch
---------------------------------------------------------
Obsoletes: spacewalk-ssl-cert-check < 1.8
Provides:  spacewalk-ssl-cert-check = 1.8
Obsoletes: %{name} < %{version}
Provides:  %{name} = %{version}
Then yum will correctly upgrade from rhn-ssl-cert-check-1.4-10.7.el5.noarch to rhn-ssl-cert-check-5.2-1.1.el5:1.noarch without that intermediate step.

Version-Release number of selected component (if applicable):
# rpm -q yum
yum-3.2.22-20.el5

How reproducible:
deterministic

Steps to Reproduce:
1. create package foo-1.0
2. create package bar-1.1 with:
Obsoletes: foo < %{version}
Provides:  foo = %{version}
3. create package foo-2.0 with:
Obsoletes: bar < 1.2
Provides:  bar = 1.2
4. rpm -Uvh  foo-1.0.rpm
5. create repo from all three packages and point your system to that repo
6. yum upgrade
  
Actual results:
foo-1.0 is replaced with bar-1.1

Expected results:
foo-1.0 is replaced with foo-2.0

Additional info:
Comment 1 James Antill 2013-03-12 16:44:04 EDT
 Obsoletes chains/loops should have already been fixed in later RHEL-5 releases.