Bug 152348
| Summary: | Implement vercmp functionality in Java | ||
|---|---|---|---|
| Product: | Red Hat Satellite 5 | Reporter: | David Lutterkort <lutter> |
| Component: | Server | Assignee: | David Lutterkort <lutter> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fanny Augustin <fmoquete> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 400 | CC: | hbrock, rhn-bugs |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | rhn400 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-09-28 21:00:13 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 125080 | ||
> Probably 2 needs here: > > 1) vercmp utilty function, maybe living in the packageevr class > itself That should be part of step (2) above. > 2) something that can intelligently use vercmp, an analogue to > RHN::Manifest The estimates didn't include much in the way of using the NVR comparison, but I think there should be time to implement the analogue of Manifest.pm in Java. Committed as r52219. I wound up reimplementing rpmvercmp in Java; it seems I reproduced all its quirks. Fix erroneous bug status TESTPLAN: Not testable by QA, since this bug only implements internal utility functionality. Verified, closing. |
From an email exchange between bretm and me: > > In the perl code, we sometimes to RPM version comparisons. Basically, > > if we have name, version, release, arch, and possibly epoch for 2 > > different packages, we need to basically be able to tell >, >=, <, <=, > > etc. > > > > The clearest example of this is in RHN::Manifest. It's how we > > represent a package manifest. The guts are pretty ugly and kludgey, > > but grep on it to see how it's used, and you'll understand our needs. > > (1) Understand the perl code and come up with appropriate > test data that ensures Java code behaves identical to > perl code 8hrs > (2) Implement a class to represent an RPM version and > the comparison function; write tests that use test > data from (1). 8hrs > (3) Find and refactor places that already work with EVR > (like PackageEvr) to make sure we only have one > implementation of the same thing 8hrs > > I assume that we don't need to do any additional database mappings > for this, only the logic for the comparison and some cleanup to make > sure we don't have more than one way to represent an EVR. Probably 2 needs here: 1) vercmp utilty function, maybe living in the packageevr class itself 2) something that can intelligently use vercmp, an analogue to RHN::Manifest #2 will be a prerequisite for a # of system details pages... particularly those concerning package profiles and snapshots.