Bug #78943 for ExtUtils-MakeMaker: EU::MM reports inaccurate $VERSION

Mon Aug 13 23:18:48 2012 thaljef [...] cpan.org - Ticket created

Subject:

EU::MM reports inaccurate $VERSION

EU::MM uses the "$VERSION = eval $VERSION" idiom to "normalize" the $VERSION at run time. But in the eyes of version.pm, 6.63_02 is not the same as 6.6302. This problem manifests in Module::Install::Makefile, which adds EU::MM as a build_requires and configure_requires dependency. The META generated by Module::Install::Makefile says that EU-MM-6.6302 is required. But that version doesn't really exist. The actual version is 6.63_02 which is considered "less than" 6.6302. I think the solution here is to just not "$VERSION = eval $VERSION". But I should note that this would directly contradict RT #21532. I also noticed that EU::MM and EU::MM_Unix are the only packages that use this idiom, so it does not appear to be systematic practice. Also, Module::CoreList shows the EU::MM version (correctly) as 6.63_02. I think it is a bit dubious that perl ships with a module that has a developer $VERSION number. But that is a another matter. What do you think? -Jeff

Tue Aug 14 02:20:40 2012 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Mon Aug 13 23:18:48 2012, THALJEF wrote: Show quoted text

> EU::MM uses the "$VERSION = eval $VERSION" idiom to "normalize" the > $VERSION at run time. But in the eyes of version.pm, 6.63_02 is not the > same as 6.6302. > > This problem manifests in Module::Install::Makefile, which adds EU::MM > as a build_requires and configure_requires dependency. The META > generated by Module::Install::Makefile says that EU-MM-6.6302 is > required. But that version doesn't really exist. The actual version is > 6.63_02 which is considered "less than" 6.6302. > > I think the solution here is to just not "$VERSION = eval $VERSION". > But I should note that this would directly contradict RT #21532. I also > noticed that EU::MM and EU::MM_Unix are the only packages that use this > idiom, so it does not appear to be systematic practice. > > Also, Module::CoreList shows the EU::MM version (correctly) as 6.63_02. > I think it is a bit dubious that perl ships with a module that has a > developer $VERSION number. But that is a another matter. > > What do you think?

I *think* $VERSION = eval $VERSION would be safe if the dev version had the _xxx tacked on to the end, instead of having the underscore inserted. (I.e., the number of digits before the underscore should match the number of digits when there is not underscore.) I’m not sure.

Tue Aug 14 02:20:41 2012 The RT System itself - Status changed from 'new' to 'open'

Fri Sep 28 14:51:15 2012 thaljef [...] cpan.org - Correspondence added

On Mon Aug 13 23:20:40 2012, SPROUT wrote: Show quoted text

> I *think* $VERSION = eval $VERSION would be safe if the dev version > had the _xxx tacked on > to the end, instead of having the underscore inserted. (I.e., the > number of digits before the > underscore should match the number of digits when there is not > underscore.) I’m not sure.

I don't understand what you mean. From the version.pm docs: Note that "alpha" version objects (where the version string contains a trailing underscore segment) compare as less than the equivalent version without an underscore: $bool = version->parse("1.23_45") < version->parse("1.2345"); # TRUE See version::Internals for more details on "alpha" versions. As I understand that, versions with an underscore are never equivalent to one without. So "$VERSION = eval $VERSION" would never produce a $VERSION that is equivalent to the $VERSION before the eval. This makes my head hurt :( In any case, I think the right thing to do is make a new release of EUMM to CPAN. It looks like the next version number is supposed to be 6.64. That way, folks can get a satisfactory version of EUMM, regardless of whether they need 6.6302 or 6.63_02. As it stands now, the latest EUMM isn't even in the CPAN index, despite being shipped with perl-5.16. Who do I need to persuade to make that happen? -- Jeffrey Thalhammer Imaginative Software Systems www.imaginative-software.com

Thu Dec 27 00:22:14 2012 mschwern [...] cpan.org - Correspondence added

It just occurred to me that we bundle version.pm now. Might as well use it. Would it clear up the problem if $VERSION was a version object?

Wed Jan 02 14:19:45 2013 rt-cpan [...] trout.me.uk - Correspondence added

On Fri Sep 28 14:51:15 2012, THALJEF wrote: Show quoted text

> I don't understand what you mean. From the version.pm docs: > > Note that "alpha" version objects (where the version string contains a > trailing underscore segment) compare as less than the equivalent > version without an underscore: > > $bool = version->parse("1.23_45") < version->parse("1.2345"); # TRUE > > See version::Internals for more details on "alpha" versions. > > As I understand that, versions with an underscore are never equivalent > to one without. So "$VERSION = eval $VERSION" would never produce a > $VERSION that is equivalent to the $VERSION before the eval. This makes > my head hurt :(

Yes, that does eem like a stupid mistake in version.pm's logic given how far the 'eval $VERSION' approach predates it. CPAN.pm does - for ($l,$r) { s/_//g; } before doing its comparisons, which produces sensible results. Show quoted text

> In any case, I think the right thing to do is make a new release of EUMM > to CPAN. It looks like the next version number is supposed to be 6.64. > That way, folks can get a satisfactory version of EUMM, regardless of > whether they need 6.6302 or 6.63_02.

Given CPAN.pm treats 6.63_02 as satisfying 6.6302, what's getting this wrong?

Mon Aug 05 15:34:51 2013 BINGOS [...] cpan.org - Correspondence added 10 min

Module::Install::Makefile was fixed in 1.05 https://metacpan.org/diff/release/ADAMK/Module-Install-1.04/ADAMK/Module-Install-1.05#lib/Module/Install/MakeMaker.pm Moving forward there is a p5p preference that core doesn't ship with dev versioned modules, especially EUMM. Many thanks.

Mon Aug 05 15:34:52 2013 BINGOS [...] cpan.org - Status changed from 'open' to 'resolved'