Bug 106031 - RPM has trouble with RH9 style release numbers
RPM has trouble with RH9 style release numbers
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-02 00:53 EDT by Need Real Name
Modified: 2007-04-18 12:58 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-05 09:20:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2003-10-02 00:53:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
RPM considers 80 to be newer than 9, so for example, nfs-utils-1.0.1-2.80 is
"newer" than nfs-utils-1.0.1-2.9

This makes upgrading a recently up2date RH 8.0 box to RH 9 very messy.

Version-Release number of selected component (if applicable):
rpm-4.2-0.69

How reproducible:
Always

Steps to Reproduce:
1.Install RH 8.0
2.Run up2date -u
3.Upgrade to RH 9
    

Actual Results:  Not all packages where upgraded including glibc which causes
problems with using RPM.

Expected Results:  Release numbers should have remained consistent with previous
formating such that RH9 releases end with "90" or the target OS release number
should be a seprate field from the release number such that RPM can
intelligently decided that nfs-utils-1.0.1-2-8.0 is NOT newer than
nfs-utils-1.0.1-2-9.  Hence, RPM would put preference on target OS before
version and release numbers.

Additional info:
Comment 1 Jeff Johnson 2003-10-04 20:58:47 EDT
Packaging, not rpm, problem. No way can rpm comparison be changed.
Comment 2 Need Real Name 2003-10-05 08:42:45 EDT
Where in bugzilla do I complain about RedHat packaging problem?

Btw, the Maximum RPM indicated that RPM was a much more flexiable format
allowing for the addition of future fields in the header.  Such a claim would
also imply that a target OS release version field could be added and the version
comparison code only changed if the field exists.

Your responce seems counter to the claims of the Maximum RPM.  Has updates since
publishication of the book made RPM less flexiable?
Comment 3 Jeff Johnson 2003-10-05 09:20:24 EDT
Adding tags is easy, defining the semantic interpretation
for new tags is the harder part.

Packages are often not built targeted for a specific distro
release. And packages built for one target are often reused
for the next target. So adding a target OS release is unworkable.

Bugs should be reported against the package that exhibit
problems.


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