RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Generalizing EVR comparison precedence, preliminaries

From: devzero2000 <pinto.elia@gmail.com>
Date: Fri 09 Jan 2009 - 17:05:53 CET
Message-ID: <b086760e0901090805u1c54647p4f16e3e07e3b0694@mail.gmail.com>
On Fri, Jan 9, 2009 at 12:03 AM, Jeff Johnson <n3npq@mac.com> 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
>
>
Received on Fri Jan 9 17:05:54 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.