RPM Community Forums

Mailing List Message of <rpm-devel>

Re: [CVS] RPM: lua/local/ lrexlib.c rpm/ CHANGES INSTALL configure.ac rpm/...

From: Jeff Johnson <n3npq@mac.com>
Date: Wed 01 Aug 2007 - 19:14:20 CEST
Message-Id: <02709F03-A2EA-4A25-BE98-46339670CDC9@mac.com>

On Aug 1, 2007, at 12:52 PM, Jeff Johnson wrote:

>
> rpmmire started off life as a way to support query's with patterns.
>
> The functionality is entirely undocumented but quite general.
>
> E.g.
>     rpm -qa 'arch=!i[3456]86'
> will list everything but the platforms that match.
>
> There are several flaws with retrieval by pattern:
>     1) pig slow because sequential serach needs doing
>     2) the patterns are intrinsically limited by tag structure, so
>          patterns against N-V-R have surprises. Consider
>                kernel-2.6*
>          as an example where the pattern does not do what is expected.
>
> The tag pattern matching functionality should be ripped or made  
> generally available on the CLI,
> right now its rpm -qa only secret sauce.
>

I 'spose I should hint at other issues now that PCRE is inevitable,  
sigh.

Featlet/bugture requests to speed down ;-), say, rpm -qa, are a  
monthly occurence,
at least for me.

The most recent request came from PLD, I fergit whether rpm-devel or  
pld-devel.

The query speed issue is signature/digest checking and methadrine  
freaks who can't help themselves.
There are various hacks to just read the inverted list indices, but  
one loses
--queryformat functionality with the quick-and-dirty hacks.

One way to beat off the endlessly feeping creatures is to add a  
memoization layer to rpm queries,
with a simple rpmdb-not-changed additional side effect, and just  
return the results
of the previous query when the query is repeated.

Memoization with patterns should work just fine, and is directly  
relevant to the
"pig slow" sequential retrieval that I alluded to now that PCRE ->  
mire is happening.

In case you did not ask: memomization was part of my rationale for  
including lookup3.c et al
into rpmio/*.

The N**3 algorithm failure (see old rpm-devel mailing list 4/1/2007)  
might be better
solved through memoization as well rather than mucking about with the  
join key as
Michael Schroder's OpenSuSE patch has done.

Michael: One flaw with your patch is that rpm _WITHOUT_ the patch  
segfaults
until --rebuilddb is done. You likely know that already, but the  
segfault creates
a support problem for rpm ...

73 de Jeff
Received on Wed Aug 1 19:14:35 2007
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.