On Wed, May 06, 2009, Jeff Johnson wrote:
> While muddling through how to add rpmvercmp to JavaScript,
> I find myself thinking Yet Again about how silly and feeble
> and fragile and deficient rpmvercmp actually is.
>
> So I ask the question:
> Can *RE patterns that match newer but not older
> packages be devised?
>
> The general answer is boring: No, of course not.
Yes. RE's are good for _parsing_ individual versions into their parts,
but _comparing_ two versions should be done by comparing the parts
theirself after an RE parsing step. And this comparison is indepenent of
the RE parsing step itself.
So, IMHO what RPM should do is this:
1. There should be a PCRE-based version parsing macros defined
similar in spirit to what "__VER__" expands to in vcheck(1) but which
has the focus on parsing a version into its _parts_:
%__rpm_version_part_parse (\d+|[^\d]+)
%__rpm_version_part_map (?g)[._-]+ "" \
(?i)^(?:d|dev(?:el)?)$ 0 \
(?i)^(?:s|snapshot)$ 1 \
(?i)^(?:a|alpha)$ 2 \
(?i)^(?:b|beta)$ 3 \
(?i)^(?:rc|candidate)$ 4 \
(?i)^(?:|r|release)$ 5 \
(?i)^(?:pl|patch)$ 6
This maps "0.9a7" to [0,5,9,2,7], "1.2.3" to [1,5,2,5,3], etc.
2. Then RPM should have a default implementation for comparison
which just compares the numbers of those result arrays, similar to
what rpmvercmp() does: first the first numbers, then the second
numbers, etc. Once one array is exhausted the comparison stops, too.
Additionally RPM should allow this comparison to be implemented
in an arbitrary embedded language via a macro:
%__rpm_version_compare %{...: ....}
This macro receives the two arrays and has to return -1, 0, +1.
This way the whole version comparing stuff is fully pluggable, as one
can define how a version is parsed into its chunks and second how those
chunks are compared.
> But %track (and /usr/lib/rpm/vcheck.pl) are based
> on *RE's and Get It Right! (i.e. detecting newer
> upstream versions of tarballs) sufficiently often
> that newer EVR comnparisons might be done with *RE's
> rather than the usual slice-n-dice of alpha/digit/other
> character sets and using strcmp(3).
The slice-n-dice is still present in my above RE solution, of course.
I don't think one can get rid of this. Even vcheck(1) internally does
something like this. Its __VER__ regex is just for matching the whole
version, not for comparison.
> Perhaps a better (as in easier to answer) question is
> How many types of versioning pattern templates would
> need to recognized for rpmvercmp to be done
> using *RE's instead?
I think the above two macros and their REs are suffcient. The first one
is applied repeateadly to determine the parts, the second ones REs are
applied in sequence on each resulting part for canoncalization/filter
purposes. The result always should be an array of numerically (and this
way easily) comparable parts.
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
