RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Generalizing EVR comparison precedence, preliminaries

From: Jeff Johnson <n3npq@mac.com>
Date: Fri 02 Jan 2009 - 21:00:22 CET
Message-id: <6708EE39-5E95-42AF-8CA6-A374F484747C@mac.com>

On Jan 2, 2009, at 1:49 PM, Ralf S. Engelschall wrote:

> 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

All that I meant to say is that with the original PCRE pattern,
then %evr_tuple_select is fully deterministic (afaict), the value for
E is always in the first {rm_so,em_eo} postion, V in the 2nd, etc etc.

Anything that is not matched is not present.

And so with what is currently checked in, there is no need for
%evr_tuple_select under the (quite reasonable) current assumptions:
	1) the 4-tuple in dependencies is {E,V,R,D}
	2) the separators are either "-" or ":"
	3) left-to-right E:V-R:D is what everyone is likely to specify

As long as the returns from the RE parser cover 1-4 uniquely (i.e. no  
sparseness
due to pattern matching artifacts), the specification syntax can be
permuted to any other left-to-right precedence, and the inverse
of the syntax permutation can be buried into the precedence permutation
to leave all EVRD comparisons invariant even if, say, LSB started
dictating that all dependencies should be specified in reversed
form like
	Requires: D:R-V:E
in "LSB format" packaging. All that would be needed to undo the syntax
permutation is to specify the precdence permutation as
	%evr_tuple_order DRVE
instead, and the existingbehavior is preserved (afaict, who knows what  
evil lurks in RE's ;-)

>
> %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?
>

We agree "fully generic".

And I fully admit to an aesthetic fetishism whenever I see numbers
exposed into a configuration. I have a similar aversion to the "N" in
	SourceN:
	PatchN:
in *.spec files. The implicit position, not the tedious "N", could/ 
should have determined
source unpacking and patch application ordering quite easily, with equal
generality, to the existing implementation.

(aside)
I can also digress into RPMTAG_PRIORITY, the arbitrarily specified
tie-breaking number used in apt-like packaging, or into the SuSE
dependency "strength" parameter. Each of those exposes a number  
needlessly
(imho) into configuration. But let's just say I have an aesthetic  
aversion
fetish to numbers.

And here's the test of "generality" that I mentally applied to your  
configuration.

A couple years back, RPM and xpkg were competing package manager  
choices for DarwinPorts.

RPM (of course) uses {E,V,R} for versions, xpkg chose {MAJOR,MINOR} as a
2-tuple for its own versioning purposes. The hysterical baggage from the
DarwinPorts competition is still in RPM as
	RPMTAG_XMAJOR = 1179, /* i */
	RPMTAG_XMINOR = 1180, /* i */

So the "generality" test I applied was
	Can I think of a configuration and pattern that captures  
{XMAJOR,XMINOR} versioning?

And of course I can, either configuration syntax, but then there's my  
fetish ;-)

The problem is not just RE pattern mapping through parsing. There's  
another mapping
onto header tags to populate rpmds arbitarily, see rpmVersionCompare()  
in
rpmdb/rpmevr.c for another place that the precedence permutation needs
to be implemented. There are many candidate, right next to Distepoch:
there is RPMTAG_DISTTAG already proposed by Per Oyvind, and there is  
RPMTAG_REPOTAG,
and RPMTAG_CVSID and RPMTAG_SVNID and (sometime) RPMTAG_GITID that all  
might
reasonably need to be expressed into dependency syntax. The list of ways
to "identify" packages is endless, and many of those identifications
already expect to be able to abuse EVR (now EVRD) comparisons and  
ordering.

And for __FULL__ generality, the EVR tuple is merely part of a  
{N,EVR,F} triple
that determines the connectivity in the package dependency graph. The  
node <-> edge
connectivity, not the syntax used to express edges, is what is  
fundamentally important,
syntax is what one discusses at the bikeshed.

Short answer: I'll do it your way. It Really Doesn't Matter ;-)

73 de Jeff




  • application/pkcs7-signature attachment: smime.p7s
Received on Fri Jan 2 21:00:27 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.