2009/1/3 Jeff Johnson <firstname.lastname@example.org>
> With this patch, the basics to introduce a precedence
> permutation into EVRD comparison should now be in place on HEAD.
> Yes, I'm still in denial about PCRE <-> ERE issues, and
> most certainly a gather operation to collect parsed
> sub-patterns is absolutely needed for "full generality".
> There's also some chrome buffing with error returns, as
> well as nuking the old <-> new assert construction scaffholding.
> But there's Yet Another parser called parseRCPOT() in
> build/parseReqs.c that needs to be converted to regexes
> like %evr_tuple_match first.
> This opens another class of issues related to build != install machines.
> Its easy to imagine that rpmbuild needs a different parsing
> pattern for EVRD than is used for EVRD comparisons during install,
> that's generally true because build != install hosts.
> And, its not too hard to see that different syntax/precedence permutations
> on the EVRD tuple might be used to, say, satisify the mythical LSB
> "standard" that all
> dependencies in "LSB format" packages need to be written as
> Requires: N = D:R-V:E
> (i.e. always reversed in package tag content), or to satisfy the cAos
> distro "feature"
> that deletes Epoch: wherever it is found, or the OpenPKG RFE to delete
> V and D wherever it is used, and likely everyone but Per Oyvind's desire
> to not use D at all because the mysterious Epoch: is already too much pain.
> What I'm suggesting is rewriting (by permuting or deleting tuple elements)
> parsed EVRD tuple before adding to a header while building packages.
> So there's likely going to be a need to duplicate the existing pattern
> and permutation macros for building afaict.
> But I'll use the existing macros while attempting to rewrite the
> parseRCPOT() parser.
> Note also: If (or when) this implementation is settled in on HEAD, I'm
> likely to aggressively push the changes all the way back to the -r rpm-4_5
> This is exactly the type of profound change, like the added
> relation, that I want everywhere, so that I don't get hung up with multiple
> branch development.
> If a profound change is broken or screwy somehow, well, its __EVERYWHERE__
> broken or screwy.
> That's the rule I try to live by.
> Meanwhile, I ain't hurrying a bit, I'll get there when I get there, not
> before ...
I look forward to the next little feature I implement which you'll go on and
something much more and state of the art, absolutely encouraging in
Now the pcre beast needs to be dealt with next. :D
Received on Sun Jan 4 00:06:36 2009