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
> depends on the PCRE library and no longer can use a the POSIX regex
> 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
> whether it is acceptable for others. OTOH, PCRE is a harmless little
> library and it should not really harm if RPM has a mandatory
> 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
"emulation of the POSIX regex API" is noted, its the PCRE/ERE dialect
to be distinguished. Its quite confusing to sort issues when the same
sometimes supports PCRE's, and sometimes doesn't. Even though the root
is obvious, the failure modes can be quite obscure.
No matter what POSIX ERE's have been, and need to be supported in RPM.
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
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
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
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
and discussion. But the proposed/planned/identified/whatever
in 5) - 7) are quite obvious (to me anyways), and add useful RPM
73 de Jeff
Received on Sat Jan 3 15:12:11 2009
- application/pkcs7-signature attachment: smime.p7s