While I don't have an answer for you, my concern with any change to rpmvercmp is 
around compatibility.. bugs become features....

What I've never seen well documented is the actual algorithm that rpmvercmp uses 
for it's comparison (in a human readable form).  I attempted to write one once 
and I can dig it up if it will help... but I'm not even 100% sure it's really 
correct.

As for using RE, it should be possible to simplify the rpmvercmp and do it for 
same pattern upgrades, but when the pattern changes thats where we would need to 
fall back to rpmvercmp rules.  (note, I think it's important someone document 
the deb vercmp as well..  I know we had a discussion on this a few years back 
and they were ALMOST the same, but not exactly...)

--Mark

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.
> 
> 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).
> 
> 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?
> 
> 73 de Jeff
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org