RPM Community Forums

Mailing List Message of <rpm-devel>

Re: [CVS] RPM: rpm/ CHANGES rpm/rpmdb/ rpmevr.c

From: Per Řyvind Karlsen <pkarlsen@rpm5.org>
Date: Sun 04 Jan 2009 - 00:06:35 CET
Message-ID: <534660c60901031506of59de24r253f8e84539b4c98@mail.gmail.com>
2009/1/3 Jeff Johnson <n3npq@mac.com>

> With this patch, the basics to introduce a precedence
> permutation into EVRD comparison should now be in place on HEAD.
> (aside)
> 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)
> the
> 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
> *very*
> likely to aggressively push the changes all the way back to the -r rpm-4_5
> branch.
> This is exactly the type of profound change, like the added
> erase-before-install
> 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 ...
> Enjoy!


I look forward to the next little feature I implement which you'll go on and
turn into
something much more and state of the art, absolutely encouraging in
more! :D

Now the pcre beast needs to be dealt with next. :D

Per Řyvind
Received on Sun Jan 4 00:06:36 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.