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
2) something that can intelligently use vercmp, an analogue to
#2 will be a prerequisite for a # of system details
pages... particularly those concerning package profiles and
> Probably 2 needs here:
> 1) vercmp utilty function, maybe living in the packageevr class
That should be part of step (2) above.
> 2) something that can intelligently use vercmp, an analogue to
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
Not testable by QA, since this bug only implements internal utility functionality.