Show quoted text > I'm a touch concerned that rpmvercmp('x', 'y') and rpmvercmp('y', 'x') can
> yield the same results with x != y...
Nonetheless, this is precisely what RPM of that vintage did, and
the point of this code is to faithfully reproduce that. Bugs and all.
Changing the behavior of an API (especially in cases where some
aspect of the API is buggy) ripples unpleasantly. The best case is
typically to do as I suggest; invent more API with parametization for
selecting your mode of suffering, and document the problem. Old code
that counts on the broken behavior doesn't break. Old code that is
unaware of the breakage is no more or less broken than it already was,
and will be discovered if it causes a problem. New code uses the
newer APIs as appropriate to it.
Show quoted text > AFAIK, there isn't one :-)
There's definitely some sort of module in the RPM source I
downloaded; I *assume* that redhat actually installs it. Even without
it, you can use the rpm shell command to produce sorts in some limited
ways (don't ask me how, it was several years ago and I'm blessedly not
running anything redhat derived now).
Show quoted text > If I write a patch, will you incorporate it?
Perhaps with style modifications as needed, but certainly in
essence. Research into changes of the version sort algorithm may be
in order; I'm aware of this one, but there may have been more.
The original point of this module was to provide the version sort
algorithm to systems without any dependance on the RPM tool chain (I
had code doing maint work for RPM based systems that were not
themselves RPM based). That's sufficient reason to keep the code
alive should someone be in a similar case, but fragility vs redhat
arbitrarily changing the version sort spec will come of it.
If you *don't* fall into the case of no RPM toolchain where you're
doing the version sort, you should be using the standard toolchain,
provided that you aren't depending on reproducing what it does on
other systems.
