|Do you know where your variables are?|
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.
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.