Bug 51333

Summary: rpmvercmp regression
Product: [Retired] Red Hat Linux Reporter: Peter Bowen <pzbowen+rhbeta>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED DUPLICATE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-08-09 16:11:25 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:
Attachments:
Description Flags
Revert 21392 and add comments to better explain code none

Description Peter Bowen 2001-08-09 15:55:19 UTC
This is a different bug that Bug #50977.  I am filing this seperately
because 50977 is an enhancement request, but this is a regression.

In RPM v4.0.2, which was included in RHL7.1, and released as an enhancement
for all supported versions of RHL (5.2,6.2,7.0), if RPM got confused when
comparing two versions it decided that the original RPM should stay.   In
Bug #21392, a fix was suggested, but this only made the problem worse.  Now
(RPM v4.0.3 CVS) the logic has been changed to if unsure, decide to replace
the RPM.

RPM should not change its behaviour mid-cycle.  I realize there were only
good intentions with this fix, but it is a definate regression.  It will
break the Mandrake, Connectiva, Kondara, madeinlinux, ASP, trustix, and
Scyld linux distributions if RPM v4.0.3 is released with the "fix" from
21392 applied.

I will attach a patch the reverts the change, and helps make the comments
in the code clearer as to why it was't correct.

Comment 1 Peter Bowen 2001-08-09 16:11:20 UTC
Created attachment 27073 [details]
Revert 21392 and add comments to better explain code

Comment 2 Jeff Johnson 2001-08-09 16:14:38 UTC
What's done is done, and any amount of fiddling, regressions, enhancements
need to be done collectively, not separately. So, to keep matters simple, since
whatever is gonna be done is gonna be done there, I'm going to collapse this
bug with #50977.

*** This bug has been marked as a duplicate of 50977 ***