search

thaljef / Pinto

Curate your own repository of Perl modules
https://metacpan.org/module/Pinto::Manual
66 stars 49 forks source link

Conflict between JPEACOCK/version and BINGOS/ExtUtils-MakeMaker #204

Open gmarler opened 9 years ago

gmarler commented 9 years ago

Seeing this interesting conflict between JPEACOCK/version-0.9912 and BINGOS/ExtUtils-MakeMaker-7.04 - you can only pull one or the other into a stack at any given time; for instance:

Pulling target Pinto==0.09997 to stack 20150416 Descending into prerequisites for THALJEF/Pinto-0.09997.tar.gz Downgrading package JPEACOCK/version-0.9912/version~0.9912 to BINGOS/ExtUtils-MakeMaker-7.04/version~0 on stack 20150416

And of course, vice versa, when ExtUtils::MakeMaker is explicitly needed.

Anything I can do to get more details on what's causing this conflict?

thaljef commented 9 years ago

Pinto thinks both dists have a version package. But it looks to me like one is actually called ExtUtils::MakeMaker::version. So this appears to be a bug in Pinto.

bluefeet commented 9 years ago

This bit me about a month ago, didn't have time to figure out the issue. Then it just happened again.

bluefeet commented 9 years ago

This started happening sometime since v6.98. Here's the diff: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/compare/v6.98...v7.00

(aka installing 6.98 does not remove version, but installing 7.00 does)

bluefeet commented 9 years ago

Lots of version-module related changes in that diff. But nothing seems terribly off to me, although it is a lot to digest and I could have easily missed something.

bluefeet commented 9 years ago

About once a week this bites someone at work. I think I'm just going to hack the pinto script to detect to issue and force-pull version afterwards if it sees the issue until this is fixed.

thaljef commented 9 years ago

I figured this out. Module::Metadata sees that $version::VERSION is assigned in ExtUtils/MakeMaker/version.pm which leads it to conclude that the file provides a version package. This has been discussed and it appears that @karenetheridge is working to resolve it.

For now, I'm going to hack around it in Pinto, just as we do for other oddities like common::sense.

karenetheridge commented 9 years ago

ah yes, this old beauty again... I will redouble my efforts to clear away the blockers in Module-Metadata so I can get a fix out.

bluefeet commented 9 years ago

We upgraded Pinto a couple weeks ago (0.11) and are still encountering this issue on a regular basis. :(

frioux commented 8 years ago

@thaljef could you mark it as not closed since we can't?

thaljef commented 8 years ago

I suspect this is because you've already pulled the problematic dists into your repo, so my patch doesn't really help you. What you need is a way to "fix" a distribution that's already been pulled. Sorta like re-indexing.

karenetheridge commented 8 years ago

This should be fixed in Module::Metadata 1.000028-TRIAL.

gmarler commented 8 years ago

That update to Module::Metadata does indeed seem to fix the problem.

karenetheridge commented 8 years ago

Hooray! I'm going to put Module::Metadata into blead and let it smoke there in the next perl release (5.23.4), and then if all looks good it will go stable sometime after that.

thaljef commented 8 years ago

@karenetheridge it looks like the change did make it into perl 5.24.0 as Module::Metadata 1.000031 (thank you!). However, it's only available on CPAN in a TRIAL distribution. So folks can't upgrade without upgrading perl entirely. Is it possible to make a non-trial release of Module-Metadata?

karenetheridge commented 8 years ago

ok, Module-Metadata-1.000033 is released!