On Aug 6, 2009, at 4:09 AM, Per Øyvind Karlsen wrote:
2009/8/6 Jeff Johnson
On Aug 6, 2009, at 12:26 AM, Per Øyvind Karlsen wrote:
2009/8/6 Jeff Johnson
Why are you reverting? The issue in the comment has already been
fixed by committing to
a representation for missing values.
hm, really?
I merely duplicated the hack used otherwise in rpmEVRoverlap(),
what would be the proper solution?
The proper solution (imho) is to permit bindings to set their own
missing
values. Which simplifies the code in rpmlib, a missing or
unspecified value
can either be defaulted (as in the case of Epoch:) or error'ed out.
IMO having rpmEVRparse() automatically taking care of such would be
the best, this way you'd be sure to have a standard way sure to work
for parsing strings rather than
applications using rpmlib implementing their own ways with various
success.
Lots of opinions "automatic".
Clearly a change in EVRcmp() affects every code path through EVRcmp(),
including error paths ...
For the specific situation in question which I started to poke
around with rpmEVRparse() for, it was simple strings in the form
%epoch:%version-%release vs %version-%release.
You can take a look at Pkg_compare* in http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/rpm/perl-URPM/trunk/URPM.xs?view=markup
to see the painful code example for urpmi.. :p
... and "simple strings". EVRcmp() is not a useful API for rpmlib, nor
should it attempt to correct or change arguments passed.
Does glibc try to "automate" this "missing value" passed to strcmp(3)?
char * a = NULL;
char * b = "";
...
return strcmp(a, b)l
Why should rpmlib automate "missing value" replacement?
The application, not EVRcmp, has more complete context and can supply
a better error message (or a better default) if necessary.
The issue is
What is a missing value? A NULL pointer? A "" string? An integer
zero?
NULL would be appropriate IMO and also what would be most likely to
be passed in such situations, "" feels more like an actual value as
well. :o)
Lots of opinions for what "missing" means.
NULL has the distinct disadvantage that rpmlib segfaults if not
corrected
everywhere.
The additional issue is
What is the collation sequence?
Which is subtly at odds with whatever value is attempted by EVRcmp.
collation sequence?
Not sure what is mean't by that, fill me in. :o)
When dealing with a 3- (or with a 4- using Distepoch:) its more
reliable to eliminate NULL as a possible missing value entirely
(treating as an error) when passed in.
IMO that often tends to be more about moving around responsibility
of being reliable to other places (and parties). At least
rpmEVRparse() seems to be neat and nicely enough ensuring
reliability with strings, whatever is decided upon for missing
dealing with missing values in rpmEVRcompare() is for me less
important than rpmEVRcompare() sorting it out without requiring
complete EVRD strings. :)
With "simple strings", EVRcmp() cannot tell whether NULL is an "error"
or
"missing". Nor is there any means to warn, or return an error, or
configure
a "Have it yer own way!" representation for the behavior.
If you want D "automatically" inserted, then do what every one else is
doing and rebuild your packages. Automatically inserting a constant
value
when missing is useful only because DistEpoch: is hardly being used
and its not at all clear whether DistEpoch: will ever be useful.
73 de Jeff
