RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Generalizing EVR comparison precedence, preliminaries

From: Jeff Johnson <n3npq@mac.com>
Date: Fri 09 Jan 2009 - 00:03:26 CET
Message-id: <423F40BE-1AD8-4765-B259-A26D80C4140F@mac.com>

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.

Plus I needed an excuse to learn PCRE syntax ...

I'm quite pleased with the results so far ;-)

73 de Jeff



  • application/pkcs7-signature attachment: smime.p7s
Received on Fri Jan 9 00:04:02 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.