>>>>> On Tue, 22 May 2007 01:26:54 +0000, Julian Mehnle <[EMAIL PROTECTED]>
>>>>> said:
> Andreas J. Koenig wrote:
>> Julian Mehnle <[EMAIL PROTECTED]> said:
>> > For anyone who has similar problems in the future and who reads this
>> > thread, I'd like to explain the cause of the problem explicitly (as
>> > I didn't understand it myself due to the various statements in this
>> > thread being too implicit).
>> >
>> > The problem I had is that my META.yml (generated by M::B 0.26)
>> > had version numbers of the form "2.004000", which is numerically
>> > correct, but in the new version.pm regime sorts between v2.3999 and
>> > v2.4001, as opposed to between v2.3.0 and v2.4.1 (as it was
>> > intended by me).
>>
>> You seem to mean "v2.004000", not "2.004000". The latter is a floating
>> point number, the former a v-string.
> I know. But I actually did have "2.004000", not "v2.004000", in META.yml
> as generated by M::B 0.26.
But what you are saying is that "2.004000" sorts between v2.3999 and
v2.4001, right? Can you please show us the code that backs this claim?
>> > Whereas old versions of CPAN.pm (<1.8x) perform a numerical
>> > comparison only, matching 2.004000 = 2.004,
>>
>> Sorry, no, this was never the case. CPAN.pm always did a mixed
>> string/numeric compare. Specifically "2.004000" was always sorted
>> after "2.004" and still is. Both look like floating point numbers so
>> they are treated as such. Because they are numerically equal, they are
>> compared as strings again with the effect that the longer is sorted
>> after the shorter.
> I see. Is this documented anywhere?
Not much more than t/10version.t in the CPAN.pm distro. Before
version.pm entered the game there was not much interest in this part
of CPAN.pm.
> What's the rationale for treating 1.0 differently from 1.00? I mean, we're
> talking about version numbers, not dictionaries.
The rationale is that if two version strings are written differently,
then there must apparently be a version difference that shall be
visible and not be swept under the carpet.
> Anyways, considering what you're saying, why does CPAN.pm 1.7602 treat
> 2.004000 (from META.yml on CPAN) as being _equal_or_lower_ than the
> installed qv('2.004')? (Remember, `r` in older CPANs doesn't complain
> about an out-of-date Mail::SPF, whereas in newer CPANs it does!)
I'm not sure it does. I tried current bleadperl with 1.7601 and it did
not bahave as you claim:
% /home/src/perl/repoperls/installed-perls/perl/pgkFpUm/[EMAIL
PROTECTED]/bin/perl -Ilib -MCPAN -eshell
cpan shell -- CPAN exploration and modules installation (v1.7601)
ReadLine support enabled
cpan> r Mail::SPF
CPAN: Storable loaded ok
Going to read /home/k/.cpan/Metadata
Database was generated on Tue, 22 May 2007 05:55:21 GMT
Package namespace installed latest in CPAN file
Mail::SPF v2.004 2.004000
J/JM/JMEHNLE/mail-spf/Mail-SPF-2.004.tar.gz
Also, when I use CPAN::Version directly, it tells me that they are not
equal:
% /home/src/perl/repoperls/installed-perls/perl/pgkFpUm/[EMAIL
PROTECTED]/bin/perl -Ilib -MCPAN -le '
use CPAN;
print $CPAN::VERSION;
print CPAN::Version->vcmp("v2.004","2.004000");
'
1.7601
-1
So I went on a time travel using old perls I have lying around from
smoke testing.
Then I took my [EMAIL PROTECTED] which had 1.7602 and with that
perl Module::Build trips over itself and cannot be installed at all.
Then I tried [EMAIL PROTECTED] which also had 1.7602 and I installed
current Module::Build for it then tried Mail::SPF and failed miserably
with lots of failing tests.
So I called the vcmp method directly and it does not confirm what you
claim either:
% /home/src/perl/repoperls/installed-perls/perl/pWNflGz/[EMAIL
PROTECTED]/bin/perl -le '
use CPAN;
print $CPAN::VERSION;
print CPAN::Version->vcmp("v2.004","2.004000");
'
1.7602
-1
>> > newer versions of CPAN.pm apply version.pm logic and compare as
>> > 2.004000 = v2.4000 >> v2.4 = 2.004, thus always reporting the
>> > version of the package on CPAN (whose META.yml is being read) as
>> > newer than what's locally installed.
>>
>> No, CPAN.pm and version.pm were never behaving identically. There have
>> always been edge cases, specifically in the treatment of trailing
>> zeroes, underline, other non-numeric characters.
> Great! Pardon me for saying that, but what a mess!
It's not that you have not been warned;)
> (Not necessarily
> yours, though.) "Design by committee" would probably still have been
> better than "interoperability by coincidence".
Yes, please turn on your time machine and rip the whole v-string mess
out of perl. Now. Pretty Please.
>> The above equation does not represent CPAN.pm behaviour. 2.004000 is very
>> far away from v2.4000. Every float below 3 is treated smaller than
>> v2.1000 because the maximum a floating point number below 3 can reach,
>> when converted to a v-string, is 2.999.999.999....
> Are you saying that, from CPAN's PoV, v2.1000 > 3? You can't be serious!
Please read my sentence again. Note that there is the word "below"
somewhere. Twice.
> At least version.pm doesn't agree (thankfully):
> $ perl -Mversion -le 'print(qv("v2.1000") > 3 ? "yes" : "no")'
> no
>> > The solution is to upgrade M::B to at least 0.2802 (better
>> > 0.2805) so META.yml gets generated with correctly formatted version
>> > numbers (no erroneous trailing zeros) to fit the version.pm
>> > numbering regime.
>>
>> Upgrading is always a good idea but I hope you do not insist that all
>> your users must upgrade everything because not all of them will be in
>> a position to do so immediately. Perl has a very good tradition of
>> being tolerant it what it expects and conservative in what it emits.
> I should have been slightly more explicit. Since, as I tried to explain,
> the root cause of my problem was the badly formatted version numbers in my
> package's META.yml as distributed on CPAN, it is of course only the
> _developer's_ installation of Module::Build that has to be upgraded such
> that future uploads of the package will contain a properly formatted
> META.yml.
Thanks for the clarification.
--
andreas
