Lemme split this into 2 threads to try to address
two twisted issues properly. The other thread will be
Transaction sanity checks
On Jul 12, 2011, at 8:48 AM, Jeff Johnson wrote:
>>>
>>> You need to figure a better *RE pattern, not whack in
>>> lots of gunky code to "fix it somehow".
>> Yes, I kinda suspected this certainly wasn't the most optimal
>> way to solve this.. :|
>>
>> The problem basically is that it's doing comparision of RPMTAG_NVRA
>> between the installed packaged and the package to be installed, which
>> will give us problems when only distepoch differs since RPMTAG_NVRA
>> still isn't consistent with %___NVRA.
>>
>
> There's a fundamental confusion here between "identification"
> and versioning (as used in assertion checking).
>
> The %___NVRA is there purely for "identification". Whatever
> elements you wish to add/delete in a chosen "identification"
> string can be added at will. One can also undertake encoding
> conversions, and attaching other data, from sources not
> just derived from *.rpm metadata contents if you wish to
> go to the trouble of adding a header tag/format extension
> (which can be done without changing one line of RPM code
> if necessary).
>
> OTOH, versioning is hierarchical, and depends on a sequence
> of comparison operations applied to well defined data, done
> strictly in the same order, with choices for results when
> missing (as in not present or empty, different meanings for
> "missing").
>
Your Distepoch: (and Disttag) implementation is nearly perfect (even if unlikely
to be used outside of Mandriva derived packaging).
But there's several sick hacks in need of improvement. There's
nothing whatsoever wrong with the hacks, just its time to
refactor the code to the right place.
The hard hack is re-writing the *RE pattern applied to NVRA keys.
I can/will "fix" (by refactoring and writing a better *RE) that
properly, but identifying how the problem is to be fixed is the
point of this thread.
The one wartlet with Distepoch: is
How SHOULD a {N,E,V,R,D} tuple be serialized/concatenated in a string?
There is what is currently in Mandriva 2011 (I'll use popt for explicit
example):
$ rpm -q libpopt0
libpopt0-1.16-2-mdv2011.0.i586
And there is also the "legacy compatible" (with %mkrel) concatenation that
would (not checked) look like this:
libpopt0-1.16-2mdv2011.0.i58
So the incompatibility is largely whether a '-' is added or not.
The incompatible '-' is added in %__NVRA (poifect!):
$ rpm --showrc | grep __NVRA
-14: ___NVRA
%%{NAME}-%%{VERSION}-%%{RELEASE}%%|DISTTAG?{-%%{DISTTAG}%%|DISTEPOCH? …
--------------------------------------------------------------------^ here is
the incompatibility
The fundamental problem has to do with the one or two remaining
non-identification
usage cases of RPMTAG_NVRA in RPM code.
The resolution will be to cleanly and _ENTIRELY_ split all uses of
%__NVRA and RPMTAG_NVRA from all versioning usage cases in RPM.
The subtlety (and the hacks) come from confusing the "identification" context
from the "assertion" versioning context. Yes it is _VERY_ confusing when its
just a string that needs to be sliced and diced differently depending on
whether its an "identification" (i.e. intended for human display) or an
"assertion" context.
The "assertion" context (and its what you originally agreed at least implicitly
back in 2009 when implemented) is in the pattern that splits the EVRD
string into a tuple for use by "assertion" version comparisons. You already know
(because I'm sure you've stared at the problems a zillion times) that the code
is
almost exactly what you want implemented: i.e. you really haven't had to change
much in the EVRD tuple parsing (your other check-in today was dead-on).
The parsing hint for splitting an "assertion" string into a {E,V,R,D} tuple
is a ':' as described here:
# STEP 1: Match the string and capture regex parts
# 1 2 3 4
# X ":" X "-"X ":"X
%evr_tuple_match ^(?:([^:-]+):)?([^:-]+)(?:-([^:-]+))?(?::([^:-]+))?$
OTOH, the %___NVRA "identification" and RPMTAG_NVRA (which uses %___NVRA as a
configurable
template) and the table /var/lib/rpm/Nvra (which is based on RPMTAG_NVRA and
configurable %___NVRA) are quite useful and important because its
"identification"
and package names which everyone focusses on.
So there's still a few places where RPM uses RPMTAG_NVRA in the wrong context,
one of
the places being what you just patched (I donna bother fixing properly there
because
its my belief that the test is bullshot and needs to be eliminated, not fixed).
So ultimately we have a ':' and a '-' character as explicit tuple separators
and have dueling "identification" and "assertion" parsers.
There are 2 approaches to fixing:
1) (recommended) Rip out the incompatible '-' in %__NVRA. Yes I
know how many places that needs to be fiddled out @mandriva.
2) Change RPM to never use RPMTAG_NVRA in an "assertion" context,
only in an "identification" context headed for human display. And
yes I know how many *other* places. not @mandriva, that will need
changing because I did the %__NVRA
"identification" != "assertion"
contextually sensitive split.
I don't give a h00t whether 1) or 2) is chosen as a means to resolve
this issue.
But the issue needs to be resolved: life is far to short to deal with
':' != '-' incompatibilities and dueling parsers and "Have it your own way!"
confusion repeated into RPM bug reports again and again.
Name your poison please: one or the other.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
