Bug 106031
| Summary: | RPM has trouble with RH9 style release numbers | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <bgallia> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED WONTFIX | QA Contact: | Mike McLean <mikem> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-10-05 13:20:24 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: | |||
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 problems. |
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: