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.
> 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.