RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Generalizing EVR comparison precedence, preliminaries

From: Jeff Johnson <n3npq@mac.com>
Date: Sat 03 Jan 2009 - 15:12:05 CET
Message-id: <C19131D3-F730-4518-BACD-5875C52E7ED2@mac.com>

On Jan 2, 2009, at 9:38 AM, Ralf S. Engelschall wrote:

>>
>> "Works" is all I really care. And I do appreciate any/all assistance
>> with RE writing.
>
> Well, the PCRE emulation of the POSIX regex API indeed is mainly about
> the API and not the supported patterns. Nevertheless, it means RPM  
> then
> depends on the PCRE library and no longer can use a the POSIX regex  
> API
> of any other regex library (as those usually provide just the standard
> POSIX patterns!). So, for me personally a fixed PCRE dependency is
> harmless, as I always build RPM 5 with PCRE in OpenPKG. But I don't  
> know
> whether it is acceptable for others. OTOH, PCRE is a harmless little
> library and it should not really harm if RPM has a mandatory  
> dependency
> to it IMHO...
>

The 1st report from --without-pcre has already arrived, sigh.

There are two approaches to carrying RE support in RPM. While the  
distinction
"emulation of the POSIX regex API" is noted, its the PCRE/ERE dialect  
that needs
to be distinguished. Its quite confusing to sort issues when the same  
API
sometimes supports PCRE's, and sometimes doesn't. Even though the root  
cause
is obvious, the failure modes can be quite obscure.

No matter what POSIX ERE's have been, and need to be supported in RPM.  
Otherwise
there are feature regressions (though few would miss the features).

The issue then becomes whether RPM could/should support PCRE patterns,
optionally or everywhere or nowhere, in configuration, on the CLI, and  
internally.

The tricky part with optional PCRE is that there will __ALWAYS__
need to be a ERE fallback written and tested and AutoFu to fail-over
if --without-pcre and the usage case of the pattern is "essential" to  
RPM functionality.

Current/pending "essential" RPM functionality (imho) includes:
	0) the "rpm -qa 'foo=*bar*' pattern selectors
	1) the /etc/rpm/platform platform->package affinity patterns
	2) the file tree walk pattern filters tied to "rpm -Uvh +foo"
	3) the href extraction from HTML parsing
	4) the EVR parser now being written
and I can easily see
	5) package->platform affinity patterns
	6) dependency matching using RE's
	7) "arbitrary syntax" data pattern validation for arbitrary tag content
functionality, which is even trickier to handle "optionally" because
the patterns are committed into *.rpm tag metadata, and *.spec  
recipes, for distribution.

Much of the above functionality (particularly 3-7) cannot be claimed  
as available because
PCRE patterns might be used, or no ERE fallback is available/tested.  
So far the
lack of "availability" doesn't really matter.

As a lazy schmuck, my opinion is that mandatory PCRE, possibly  
internal to RPM, with support for
both PCRE's and ERE's seems to be simplest, maximizing functionality  
and eliminating
most build choices other than internal <-> external, which really  
isn't all that hard to
support with a small slowly changing library like PCRE.

Any commitment to PCRE's into RPM package content will need careful  
thought
and discussion. But the proposed/planned/identified/whatever  
implementations
in 5) - 7) are quite obvious (to me anyways), and add useful RPM  
functionality.

73 de Jeff

  • application/pkcs7-signature attachment: smime.p7s
Received on Sat Jan 3 15:12:11 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.