RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Generalizing EVR comparison precedence, preliminaries

From: Ralf S. Engelschall <rse+rpm-devel@rpm5.org>
Date: Fri 02 Jan 2009 - 19:49:38 CET
Message-ID: <20090102184938.GA24451@engelschall.com>
On Fri, Jan 02, 2009, Jeff Johnson wrote:

> On Jan 2, 2009, at 4:46 AM, Ralf S. Engelschall wrote:
>>
>>    # STEP 2: Assemble <E,V,R,D> tuple from regex parts
>>    # <E,V,R,D>       case 1:  case 2:  case 3:  case 4:  case 5:  case
>> 6:
>>    #                 X:X-X:X  X:X-X    X:X      X:       X-X      X
>>    %evr_tuple_select 2357     237_     23__     2___     _23_     __5_
>
> This macro determines the mapping from sub-patterns to the tuple
> {E,V,R,D}.

Right.

> The scatter/gather operation in the mapping is necessary for more
> general support than what is currently implemented, where E=1, V=2,
> R=3, D=4 is assumed.

This I don't quite understand, I think. The idea is that the
%evr_tuple_select contains one or more four-character strings. Each
string's character represents one element of tuple <E,V,R,D> (and
in this order!). The character is either "1".."9" (meaning that the
capturing parenthesis with the same number should be used to derive
the value) or "_" (meaning that the corresponding element of the tuple
should be set to undefined (or NULL in C). The program has to walk
through the %evr_tuple_select strings. The first string where _not
a single_ "1"..."9" reference results in an empty/undefined result
(meaning the regex capturing parenthesis really matched) stops the whole
selection process.

AFAIK this scheme is fully generic. It allows an arbitrary complex regex
(to match whatever EVRD syntax we want) and still allows us to create
the <E,V,R,D> tuple from it. So, what "more general support" do you
think of, Jeff?

> But perhaps an alternative syntax, using the implicit position to hide
> the sub-pattern index, and having an explicit (and opaque, there's
> nothing particularly holy about "E", "V", "R", and "D" tokens as long
> as the same characters appear in the %evr_tuple_order precedence
> permutation) single character identifier for a sub-pattern match.
>
> Here's an explicit example, permutations, like daylight savings time,
> is difficult to discuss unambiguously (implicit positional example based
> on 1 rather than 0 as first index):
>
>    # STEP 2: Assemble <E,V,R,D> tuple from regex parts
>    # <E,V,R,D>       case 1:  case 2:  case 3:   case 4:  case 5:  case
> 6:
>    #                 X:X-X:X  X:X-X    X:X       X:       X-X      X
>    %evr_tuple_select _EV_R_D  _EV___R  _EV_____  _E_____  __VR___
> __V____

This I do not understand. Your %evr_tuple_select strings are 7
characters long but your tuple still seems to be just a 4-element tuple
<E,V,R,D>. Why? What are you trying to achieve. It is still not clear to
me.

> Hmmm, case 5 "_23_" might be incorrect, I would have naively expected
> "E" in position 2. Not looked (you likely have), will check and
> correct.

Ah, yes, you're right. Here is the fixed version:

    # STEP 1: Match the string and capture regex parts
    #                      2          3           5             7
    #                      X     ":"  X        "-"X          ":"X
    %evr_tuple_match  ^(([^:-]+):)?([^:-]+)(-([^:-]+))?(:([^:-]+))?$

    # STEP 2: Assemble <E,V,R,D> tuple from regex parts
    # <E,V,R,D>       case 1:  case 2:  case 3:  case 4:  case 5:  case 6:
    #                 X:X-X:X  X:X-X    X:X      X:       X-X      X
    %evr_tuple_select 2357     235_     23__     2___     _35_     __5_

    # STEP 3: Configure the comparison order of the <E,V,R,D> tuple elements
    %evr_tuple_order  EVRD

> There's also a (possible) ambiguity in case 3 "X:X" or a missing case 7
> candidate as "X::X". yawn ...

Yes, "X:X" is actually "E:V", the "X::X" for "E::D" (if this is wished
by you to be supported) then has to be case 7. Here it is:

    # STEP 1: Match the string and capture regex parts
    #                      2          3           5             7
    #                      X     ":"  X        "-"X          ":"X
    %evr_tuple_match  ^(([^:-]+):)?([^:-]+)(-([^:-]+))?(:([^:-]+))?$

    # STEP 2: Assemble <E,V,R,D> tuple from regex parts
    # <E,V,R,D>       case 1:  case 2:  case 3:  case 4:  case 5:  case 6:  case 7:
    #                 X:X-X:X  X:X-X    X:X      X:       X-X      X        X::X
    %evr_tuple_select 2357     235_     23__     2___     _35_     __5_     2__7

    # STEP 3: Configure the comparison order of the <E,V,R,D> tuple elements
    %evr_tuple_order  EVRD

This is now the non-PCRE, case-5-fixed and case-7-added version.
Please take this one now...
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com
Received on Fri Jan 2 19:49:50 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.