Configuration-Free CPAN Installations and What's Wrong with Module::Install both hinted at a fundamental difficulty in managing software from the CPAN. Enough teasing.
The fundamental assumption of the CPAN that makes managing software through CPAN clients difficult is that newer software can always replace older software.
That's not the CPAN's problem, not really. Perl 5 has this version number problem too, and it's the source of much of the backwards compatibility troubles in the Perl 5 world.
On the CPAN, no one agrees on what version numbers mean. No one agrees on backwards compatibility concerns. No one agrees about what makes one release "stable" and another release "testing" or what you can change in an API.
I'm not sure it's the job of CPAN or the CPAN maintainers to try to solve this problem. The lack of rules and ceremony over the function of uploaded code and the loose agreement on the form of uploaded code have allowed CPAN to thrive where other languages with their own packaging and distribution systems have fragmented into incompatible, warring fiefdoms.
Even still, fighting over whether Module::Build is of the devil
because (insert silly reason here) or complaining that
Module::Install is a stupid patch over a pile of nasty, almost
unsupported hacks misses the real point. The best possible improvement in the
Perl 5/CPAN ecosystem is to know which versions of which distributions work
together, and for end users to be able to download a known-working graph of
their desired distribution and its dependencies.
In other words, the big problem isn't that Module::Install has
a nicer interface (arguable) or ExtUtils::MakeMaker is a horrific
pile of barely-working hacks that shouldn't have survived into the 21st century
(indisputable). The problem is the integration of separate components managed
by separate maintainers with wildly disparate ideas of the semantics of change
over indeterminate periods of time.
At any single given point in time, any given CPAN distribution should work correctly with its currently available upstream dependencies. With the current system, we cannot guarantee that perturbation in those dependency graphs will percolate to users at any point in the future.
In my mind, arguing over whether an improvement to the CPAN ecosystem can take over for every use case of the current tools is stupid and wrong (or, more charitably, a silly distraction). Improving the user and developer experiences of the current tools and the current system is good, but the real improvements in the system will not occur at the interface level.
(Of course, the problem with Adam's point of view is that requiring any credible replacement to handle every possible failure case before stamping it with an imprimatur is that "better" is not an all or nothing concern. I have no illusion that it's possible to fix the Perl 5 versioning scheme for every case. If we can fix it for 90% of cases, surely that's a reasonable improvement.)
This is why I would love to have a standard way of installing tests in a separate directory from the code. Then, after you've installed the code, you could rerun the tests for your entire installation and see if anything breaks.
Never quite got agreement from folks on how to set that up, but I think it would mitigate the problem. The main issue with this approach is that tests would generally take so long to run that people might very well install quite a few modules before remembering to test their installation. When that happens, you don't know what broke things (that being said, it's still better to know something is broken than not). Also many test suites are quite finicky and hard to run, but that's a separate issue -- though it does impact on this idea.
One solution I see is to have a new download option on CPAN that offers an entire known-working dependency stack along with the module. (Using the same dependency versions the author tested with). This would ease installation compared to having new users (or non-Perl-programmers) wrangling with a cpan client. Yes, the approach brings up new concerns about multiple copies of the same modules in different projects, and binary vs Pure Perl, but I think the trade-offs are solvable and worthwhile.
After all, isn't this more like how easy-to-use commercial software installers work? You find Photoshop and you pick a platform and you're done. You don't wrangle with getting a dozen different dependencies in order, dependencies which other software packages might depend on too... but necessarily the same version that you need for the new project.
http://perldoc.perl.org/perlmodstyle.html#Version-numbering
If they don't follow that...can't it be changed when then try to insert it into CPAN? Or...if they are not in compliance...can a BUG be opened against the module owner? It seems silly that it can't be enforced.
That always annoys me when I fire up CPAN and get "242 modules don't have a parsable version number...".