On Fri, Jan 9, 2009 at 12:03 AM, Jeff Johnson <[email protected]> wrote: > > On Jan 8, 2009, at 3:24 PM, Ralf S. Engelschall wrote: > > On Tue, Jan 06, 2009, Michael Jennings wrote: >> >> [...] >>> So a standalone number is just a release? Shouldn't that be a >>> version? (i.e., _3__ for case 6) >>> >> >> I've just implemented what Jeff told me. >> I wondered myself about this special case, too... >> >> And isn't there an ambiguity with E:V vs. V:D? What about V-R:D? or >>> just :D? >>> >> >> V:D was not part of Jeff's list, hence no ambiguite existed ;-) >> > > Ask Per Oyvind re Distepoch:. There is no ambiguity if (as currently) > there are almost no occurences of Distepoch:. Only "E:V" occurs atm. > > The resolution is likely partly to add [0-9]+ as a pattern for E, which > also is more precisely compatible with the pre-existing EVR parser, and or > to invent a different separator rather than ':' D. > > But at least the flaws are being seen at the design stages, not after > a patch has been checked-in and deployed and released, where the > only possible resolution is to pretend that what just happened in RPM > was what was intended. An accident like that with > {Dirnames,Basenames,Dirindexes} > is indeed the root of years of suspicion between LSB <-> RPM. > > So finding flaws sooner is called "progress" in my RPM scrapbook. > > >> Jeff, can you be more specific what cases you really want to support? >> > > I could be more specific if I knew specifics. > > What I'm seeking is a generalization out of traditional E:V-R dependencies > through > pattern matching and parameterization and templating within RPM. > > So I hijacked Per Oyvind's Distepoch: and stirred in a bit of your > dead-on methodology and PCRE expertise, and RPM versions (perhaps) now have > sufficient > generality that a LSB specification for "package" "versions" can be > attempted > so that indeed, the decision of a "package" "upgrade" is decidable for LSB > "packages". > > LSB details at > > https://lists.linux-foundation.org/pipermail/packaging/2009-January/001199.html > Alas, still no publically visible statement-of-work from LSB. Oh well ... > > Basically I am making "stuff" up as fast I can. I assure you, I'm not > a parser guy, I'm the last hacker in the world you want attempting > a Ragel parser based rewrite of rpmbuild using *RE's instead of ctype(3). > > But a rpmbuild rewrite seems to be my current RPM goal because YAMLspec! > is the only roadmap item @rpm5.org I'm hearing consensus about. >
Off topic. Am i the only who like the initial development of a dep-solver in rpm5 via sat-solver ? Regards > > Plus I needed an excuse to learn PCRE syntax ... > > I'm quite pleased with the results so far ;-) > > 73 de Jeff > >
