You're entitled to your own opinion, but I do disagree. Recently, I tried to install a module in a perl 5.12. This in turn required installation of Module::Build. That in turn required an update of ExtUtils::MakeMaker. And there was no way I could that upgrade installed. ExtUtils::MakeMaker depended on another module that also required to be updated, and that one in turn demanded a more recent version of ExtUtils::MakeMaker. There was no older version of either modules old enough available to upgrade both modules gently. So, I was simply stuck. Like I said, and I'll say it again: if your dependency graph is not a tree, but instead, contains a cycle, these modules in that cycle should not be in separate distributions. Otherwise your repository is plainly broken. p.s. Perl 5.12, to me, is modern enough. I cannot name a single significant difference between perl 5.12 and perl 5.24. Upgrading perl takes hours, because of the need to reinstall every module I ever installed. It's simply not worth it.

Hi,

What module was it?

I sympathize with you want new thing to work with really old thing seamlessly

but this is not caused by the cycle dependency, which perl has had for the longest time ever

its just all your stuff is really really old, 2010-Apr-12 was a very very long time ago

ExtUtils-MakeMaker alone has had

11 New Features
6 Improvements
18 Enhancements
122 Bug Fixes
33 Test Fixes
31 Doc fixes
8 Win32 fixes...

since 2010-Apr-12 ... and Module::Build had ... and so it goes

the cpan toolkit needs to be kept up to date , esp if the Makefile.PL is making use of new features

What you're really complaining about is third party politics -- you depend on some rpm repository which isn't quite up to taking care of your needs -- it happens

Kinda reminds me of this old thread :) Module::Build users -- please use the "traditional" create_makefile_pl option What's wrong with PREFIX, you ungrateful fucks.