RPM Community Forums

Mailing List Message of <rpm-devel>

Generalizing EVR comparison precedence, preliminaries

From: Jeff Johnson <n3npq@mac.com>
Date: Thu 01 Jan 2009 - 17:54:35 CET
Message-id: <71398077-D34A-47D0-83F7-985158419E3C@mac.com>
The recent patch to add Distepoch: to RPM EVR comparison is the
reason for generalizing EVR comparison precedence.

I really hated to stomp the Distepoch: patch. The major issue I had with
the patch is that it added a 4th & 5th element to the existing {E,V,R}
triple without a clearly identified need or sufficient discussion.

It matters little whether a 4th or 5th (or 101st) element is added to  
EVR comparison.
The problem is that it takes YEARS for the changes to ripple into
"production", confusing users and developers and distros continuously.

I firmly believe that adding additional tags like Distepoch: (and  
using Disttag: and Repotag:)
for package "identification" absolutely needs to happen in RPM  
packaging. Adding
Yet More Suffixes to Release: for "identification" purposes does not  
scale,
and increasingly is creating issues with detecting "newer". Any  
package manager
(or software distribution system) that cannot "upgrade" software ain't
worth using.

Years of aimless meandering discussions with Epoch: 0 and multilib  
arch and
fedora.us vepoch and %{?dist} and "The Berlin API" most definitely  
indicate that
there is __EXTREME__ interest in having RPM commit to a more flexible  
framework
for handling EVR comparisons.

The general "fully opaque" version problem is insoluble (a fatal flaw  
in "The Berlin API"
design).

However a framework that permits extending the {E,V,R} triple as a  
tuple, and permuting
the precedence order of the tuple members (in case left-to-right  
implicit precedence ordering
is unsatisfying) is feasible within RPM.

If file dependencies and other "stuff" that is carried in RPMTAG_*NAME  
EVR dependencies
is ignored, there are 5 cases that must be parsed in existing RPM  
dependencies:

	E:V-R
	E:V
	E:
	V-R
	R

with the usual defacto RPM meanings for {E,V,R}.

The attached toy script uses a RE pattern to parse E into \2, V into  
\3, and R into \4.

A RE based parser framework, extending the {E,V,R} tuple based on a  
'-' separator
to accomodate, say, Distepoch: (or Disttag: or Repotag: or ...)  
establishes a
flexible framework for extending the existing {E,V,R} tuple to a 101st  
element
and beyond.

(aside)
Note also that a RE parser, because it has a pattern attached, is rather
easy to test for conformance and specify outside of the RPM  
implementation
itself. LSB take note.

The other piece of the implementation that is needed is a precedence  
permutation
matrix for the tuple that is to be compared.

Here's a (quite predictable imho) extension to Distepoch: worked  
through in detail.

Let's say that a distro has chosen to use the {E,V,R,D} 4-tuple  
everywhere in dependencies,
but wants RPM to compare the "newer" Distepoch: before the usual EVR  
comparison.

A pattern would need to be written that populates \5 when parsing, not  
hard, add a '-'
separator, append Distepoch:.

Define a permutation of the implicit default {\2, \3, \4, \5} left-to- 
right
precedence configured along with the parsing pattern. All I'm
saying is that the desired comparison precedence ordering is
	{\5, \2, \3, \4}

One can also imagine attaching a rpmvercmp-like comparison to each of  
the
elements in the tuple to hide the data comparison operation and whatever
string representation is chosen, including binhex, if necessary, but  
let's not
go there until absolutely necessary.

Opinions? I shall likely be rewriting the EVR parsers, and adding the  
permutation,
in rpmdb/rpmevr.c over the next month or so.

73 de Jeff

===================================
#!/bin/sh

EVRcases="\
E:V-R
E:V
E:
V-R
V"

# parse EVR into \2 \3 \4
  echo "$EVRcases" |
  sed -e 's,^\(\([^:-]\+:\)*\([^:-]\+\)*\(-[^:-]\+\)*\)$,==> \1\t2:\2  
3:\3 4:\4,'






  • application/pkcs7-signature attachment: smime.p7s
Received on Thu Jan 1 17:54:42 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.