On Jan 25, 2011, at 1:36 PM, Per Øyvind Karlsen wrote:
> 2011/1/25 Jeff Johnson <n3...@mac.com>:
>>
>> On Jan 25, 2011, at 12:17 AM, Per Øyvind Karlsen wrote:
>>
>>> grf, sent this one earlier with wrong alias..
>>> 2011/1/25 Per Øyvind Karlsen <peroyv...@mandriva.org>:
>>>> 2011/1/24 Jeff Johnson <n3...@mac.com>:
>>>>> Lessess if we can get this "fixed".
>>>>>
>>>>> On Jan 19, 2011, at 8:39 PM, Per Øyvind Karlsen wrote:
>>>>>>>
>>>>>>>> To make dbiFindMatches() to match -%{disttag}%{distepoch}, I changed
>>>>>>>> _post_NVRA to:
>>>>>>>>
>>>>>>>> static const char _post_NVRA[] =
>>>>>>>> "(-[^-]+-[^-]+-[^-]+\\.[^.]+|-[^-]+-[^-]+\\.[^.]+|-[^-]+\\.[^.]+|\\.[^.]+|)$";
>>>>>>>>
>>>>>>>> This expression gets too greedy for packages with '-' in the name and
>>>>>>>> without disttag/distepoch though..
>>>>>>>>
>>>>>>>
>>>>>
>>>>> There is something I don't understand here.
>>>>>
>>>>> Let's say a NVRA key looks like this
>>>>>
>>>>> foo-1.2-3mdv2011.0.noarch
>>>>>
>>>>> That might be a {N,V,R,A} 4-tuple, or that might be a {N,V,R,D,A} 5- or
>>>>> 6-tuple.
>>>>>
>>>>> Either way the string is identical, and the existing _post_NVRA pattern
>>>>> either "works" or doesn't.
>>>>>
>>>>> So where is this "too greedy" coming from? My guess is that you have
>>>>> mixtures of strings in the NVRA index, some with "mdv2011.0", some
>>>>> without.
>>>> Yupp, that's just it.
>>
>> No, there's _STILL_ something I'm missing.
>>
>> Concatenated strings -- with or without Distepoch: --
>> will "work" without any change.
>>
>> Can you supply an example where the existing implementation
>> is "too greedy" for some input pattern applied to some set of strings?
>
> ie:
> rpm-build-1-1.x86_64
> version: build, release: 1
> vs
> rpm-build-1-1mdv2011.0.x86_64
> version: 1, release: 1
>
That defines the NVRA strings, but not the pattern.
The existing post_NVRA patterns are anchored (i.e. ^...$)
and have alternative patterns to capture with a single lookup
any of the queries
N
N-V
N-V-R
(there's also .A but that is stripped out elsewhere).
But there is no "greedy" there, only a mis-used pattern that isn't meeting
expectations. That's life imho.
(aside)
What RPM used to do with RPMDB_LABEL is gross beyond belief. Three
lookups were attempted, first with
N-V-R
then with
N-V
finally with
N
with mire pattern's for V and R and A as needed, thereby forcing
every header in an rpmdb to be read/loaded 3 times to apply the
patterns.
What is there now uses alternate *RE expressions, and a N stem with
a partial match, and patterns applied solely to NVRA keys, not
forcing header loads.
That scheme SHOULD be independent of Distag: and Distepoch: in the NVRA
index even optionally without any need to change the pre/post pattern anchoring.
And there SHOULD NOT be any "greedy" involved: the input pattern matches
or the luser needs to write the query pattern differently.
But I can't really tell unless I see an explicit test case. Try using
grep across an input file of NVRA strings to remove the goriness. That's
all that is going on in dbiFindMatches() -> dbiMireKeys() is just grep(1)
on strings in a file, its gross solely because of DB_PARTIAL_MATCH forced
into the Berkeley DB retrieval.
So what pattern are you matching against the 2 strings above in the NVRA index?
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
