Bug 7855 - RPM --upgrade doesn't work properly!
Summary: RPM --upgrade doesn't work properly!
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gftp
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-12-16 23:26 UTC by jgotts
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-08-10 22:14:57 UTC

Attachments (Terms of Use)

Description jgotts 1999-12-16 23:26:02 UTC
[jgotts@umpire SPECS]# rpm --upgrade
package gftp-2.0.6pre3-1 (which is newer then gftp-2.0.6a-1) is already

This can't be!

Also, than is spelled T-H-A-N.

Comment 1 Riley H Williams 1999-12-17 00:23:59 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.

Comment 2 Jeff Johnson 1999-12-17 14:23:59 UTC
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)

Comment 3 Havoc Pennington 2000-08-10 22:14:52 UTC
Fix for this in our local Labs directory, needs to be submitted to the tree

Comment 4 Havoc Pennington 2000-08-21 14:33:13 UTC
Should be fixed now

Note You need to log in before you can comment on or make changes to this bug.