Bug 7855
| Summary: | RPM --upgrade doesn't work properly! | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | jgotts |
| Component: | gftp | Assignee: | Havoc Pennington <hp> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0 | ||
| 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: | 2000-08-10 22:14:57 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
jgotts
1999-12-16 23:26:02 UTC
There are several packages around where it's not obvious from either the name or the build date which is the newer version as the build date on what from the version looks like the older package is the more recent one. There are also packages around where the format of the version number changes in an inconsistant way from one version to the next. I for one would be interested in discovering just how the rpm program determines which is the newer version, but the ONLY place where blame for this mess can be assigned is on the distributors of the various packages concerned, as they are the people who decide what version numbers go in the spec files, and thus into the RPM's themselves. This is a packaging problem in gftp not an rpm problem. Rpm does
segmented (i.e. numeric and alpha strings are differentiated) string
comparison (i.e. strcmp/strlen) in order to determine the newer
version-release. In the gftp case, 2.0.6pre3-1 is "newer" than
2.0.6a-1 because the 'p' in "2.0.6pre3" is greater than the 'a' in "2.0.6a".
Normally, a packager using rpm would increment the epoch number in order
to preserve the ordering required by rpm.
Mis-spelling corrected, thanks for noticing.
And, rpm does not look at build time or anything other than
epoch-version-release to determine ordering. The actual algorithm used
by rpm is in lib/misc.c rpmvercmp().
Here are the comments from that routine (look at the code if you need more):
/* loop through each version segment of str1 and str2 and compare them */
/* grab first completely alpha or completely numeric segment */
/* leave one and two pointing to the start of the alpha or numeric */
/* segment and walk str1 and str2 to end of segment */
/* save character at the end of the alpha or numeric segment */
/* so that they can be restored after the comparison */
/* take care of the case where the two version segments are */
/* different types: one numeric and one alpha */
/* this used to be done by converting the digit segments */
/* to ints using atoi() - it's changed because long */
/* digit segments can overflow an int - this should fix that. */
/* throw away any leading zeros - it's a number, right? */
/* whichever number has more digits wins */
/* strcmp will return which one is greater - even if the two */
/* segments are alpha or if they are numeric. don't return */
/* if they are equal because there might be more segments to */
/* compare */
/* restore character that was replaced by null above */
/* this catches the case where all numeric and alpha segments have */
/* compared identically but the segment separating characters were */
/* different */
/* whichever version still has characters left over wins */
(changing component to gftp)
Fix for this in our local Labs directory, needs to be submitted to the tree Should be fixed now |