Red Hat Bugzilla – Bug 106031
RPM has trouble with RH9 style release numbers
Last modified: 2007-04-18 12:58:03 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):
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.
Packaging, not rpm, problem. No way can rpm comparison be changed.
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?
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