Generalizing EVR comparison precedence, preliminaries

[Jeff Johnson]

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.


The problem is that it takes YEARS for the changes to ripple into
"production", confusing users and developers and distros continuously.


(or software distribution system) that cannot "upgrade" software ain't
worth using.


for handling EVR comparisons.


design).


is unsatisfying) is feasible within RPM.



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

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




and beyond.

(aside)
Note also that a RE parser, because it has a pattern attached, is rather

itself. LSB take note.


matrix for the tuple that is to be compared.






separator, append Distepoch:.


precedence configured along with the parsing pattern. All I'm
saying is that the desired comparison precedence ordering is
        {\5, \2, \3, \4}


elements in the tuple to hide the data comparison operation and whatever

go there until absolutely necessary.


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" |

It matters little whether a 4th or 5th (or 101st) element is added to EVR comparison. 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 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 The general "fully opaque" version problem is insoluble (a fatal flaw in "The Berlin API" 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 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: 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 easy to test for conformance and specify outside of the RPM implementation The other piece of the implementation that is needed is a precedence permutation 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 '-' Define a permutation of the implicit default {\2, \3, \4, \5} left-to- right One can also imagine attaching a rpmvercmp-like comparison to each of the string representation is chosen, including binhex, if necessary, but let's not Opinions? I shall likely be rewriting the EVR parsers, and adding the permutation, sed -e 's,^\(\([^:-]\+:\)*\([^:-]\+\)*\(-[^:-]\+\)*\)$,==> \1\t2:\2 3:\3 4:\4,'

smime.p7s
Description: S/MIME cryptographic signature