On Dec 28, 2007, at 8:04 AM, Ralf S. Engelschall wrote:

> Nothing really essential, but another thing for RPM 5.1: In OpenPKG  
> the
> "Release" tag follows a very strict semantic which actually means that
> it has to be a steadily increasing version number for the packaging
> within a particular OpenPKG distribution series. The "Version" on the
> other hand is the upstream vendor version number and can be mostly
> arbitrarily, including to jump or even go backwards (on packaging
> downgrades). In OpenPKG CURRENT the "Release" tag simply is YYYYMMDD,
> for other series it is M.N.K, etc.
>
> In practice I'm regularily faced with the situation that I logically
> need to assert just the "Release" of a package in a dependency instead
> of "[E:]V-R" -- mainly because I assert the packaging itself and not
> the stuff which is packaged. In those scenarious I do not care about
> the version at all. But because the version is *NOT* guarrantied to
> steadily increase, a dependency like "N >= V-R" is problematic:  
> although
> if R increases, if V decreases the dependency fails (again). But RPM
> AFAIK doesn't support something like "N >= *-R" or perhaps "release(N)
>> = R". Additionally, the specification of "V" in "N >= V-R" is not  
>> just
> problematic, it is also confusing after some longer time, because  
> if one
> sees the dependency again one thinks it is a dependency to a  
> particular
> version and no longer recognize from the dependency that it actually
> logically was a "Release" assertion.
>
> So, questions:
>
> 1. As of today can a "Release" be asserted in a dependency at all?
>    (I think: "no")
>

Well, Release: is definitely used in EVR comparison.

What you seem to want want is a change in the hierarchical precedence  
ordering of
     1) Compare Epoch:
     2) Compare Version:
     3) Compare Release:
from EVR to ERV or REV.

It would not be hard to add, say
     %define version order REV
and then rewrite the 1-2 places in rpm where the {Epoch, Version,  
Release}
tuple is compared in order to make the hierarchical precedence  
configurable.

An alternative approach will be needed for dpkg EVR comparison,
where the collate sequence changes, rpm <-> dpkg dependencies
have similar EVR comparison precedence. Plugging a different  
(*EVRcmp) vector
is an alternative approach that could also do comparisons in ERV or  
REV ordering.

The really hard problem is mixed-mode:
    How does one compare two versions if one is EVR and the other is  
REV?

> 2. What would be the best syntax?
>    (I think "N >= *-R" is very natural and "release(N) >= R" would be
>    also acceptable and is certainly what Jeff will recommend)
>

There's a core representational problem that should be solved first.
Dependencies all conform to the template
	E:V-R
In order to split out the triple {E,V,R} there are heuristics such as
E can only be digits, and that neither V nor R can contain '-'.

Some modest thought can devise a means to serialize a {E,V,R}
triple containing patterns and missing values and permitting '-' and
E as a string and ... unambiguously.

The really hard problem is proving that the change breaks nothing
in all possible cases.

73 de Jeff