Bug 150853

Summary: rpm obsoletes not functioning properly
Product: Red Hat Enterprise Linux 2.1 Reporter: Jay Turner <jturner>
Component: rpmAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED NEXTRELEASE QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.1CC: herrold, katzj, nobody+pnasrat, srevivo, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://linux.duke.edu/~skvidal/broken/
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-27 21:12:46 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 Jay Turner 2005-03-11 13:13:34 UTC
+++ This bug was initially created as a clone of Bug #142272 +++
Seeing the same behavior on 2.1 with rpm-4.0.4-7x.20.


*** This bug has been split off bug 134497 ***

Description of problem:
rpm is not obsoleting packages correctly.

Version-Release number of selected component (if applicable):
rpm-4.2.3-10

How reproducible:
every time.



Steps to Reproduce:
1. Download i686 rpms from http://linux.duke.edu/~skvidal/broken/
2. rpm -ivh baz-0.1-1.i686.rpm
3. rpm -q baz
4. rpm -qp --obsoletes quux-0.1-1.i686.rpm
5. you'll note it obsoletes baz >= 0.1
6. rpm -Uvh quux-0.1-1.i686.rpm
7. rpm -q quux - it's installed
8. rpm -q baz - it's still installed too!

Actual results:
baz is still installed

Expected results:
baz should have been removed.


Additional info:

------- Additional comment by Seth Vidal on 2004.10.04 10:57 -------

looks like if the version of the obsoleting package is not <= then it
will work correctly.

but if obspackage-evr is <=  installedpackage-evr then it won't remove
the other.


------- Additional comment by Paul Nasrat on 2004.10.04 11:00 -------

Relevant diff between RHL9 to HEAD, reversed on HEAD

--- depends.c   2003-03-03 22:12:00.000000000 +0000
+++ /export/anu/home/pauln/src/rpm/lib/depends.c        2004-04-01
13:56:54.000000000 +0100
@@ -305,7 +305,8 @@
             */
            if (rpmdsEVR(obsoletes) == NULL
             || rpmdsAnyMatchesDep(oh, obsoletes, _rpmds_nopromote))
-               xx = removePackage(ts, oh, rpmdbGetIteratorOffset(mi),
pkgKey);
+               if (rpmVersionCompare(h, oh))
+                   xx = removePackage(ts, oh,
rpmdbGetIteratorOffset(mi), pkgKey);
        }
        mi = rpmdbFreeIterator(mi);
     }


------- Additional comment by Jeff Johnson on 2004.10.04 14:00 -------

The added line prevents obsoleting package with identical NEVR.

This was important bug fix for major customer (I can tell from
when the fix went in), but for the life of me, I cannot remember the
problem report. Perhaps relocated packages, perhaps multilib.

------- Additional comment by Seth Vidal on 2004.10.04 14:02 -------

it also prevents obsoleting package identical EVR, not just NEVR


------- Additional comment by Jeff Johnson on 2004.10.05 17:08 -------

Fixed (by reverting the 1 line change) in rpm-4.3.2-9.

------- Additional comment by Dave Lehman on 2004.12.02 18:07 -------

Can we get this fixed in RHEL-3 branch as well, please?

Comment 1 Jeff Johnson 2005-03-11 13:16:20 UTC
What fix is needed? There are several changes here, and
I'm not sure which one you want reverted or back ported.

Comment 3 Paul Nasrat 2005-09-27 21:08:04 UTC
*** Bug 150854 has been marked as a duplicate of this bug. ***

Comment 4 Jeremy Katz 2005-09-27 21:12:46 UTC
This problem is resolved in the next release of Red Hat Enterprise Linux. Red
Hat does not currently plan to provide a resolution for this in a Red Hat
Enterprise Linux update for currently deployed systems.

With the goal of minimizing risk of change for deployed systems, and in response
to customer and partner requirements, Red Hat takes a conservative approach when
evaluating changes for inclusion in maintenance updates for currently deployed
products. The primary objectives of update releases are to enable new hardware
platform support and to resolve critical defects.