The $title was a common joke that our administrators used to have about different SW "features" and "improvements" hidden inside.
One of "those" got me yesterday. It was actually Wednesday ;-) but anyway. Some authors do actually write you a comment, so that can't say you haven't been warned:
installdirs( 'perl'); # This overwrites a core module!
some don't:
INSTALLDIRS => ($] >= 5.009 ? 'perl' : 'site'),
installdirs => ($] >= 5.009004 ? 'core' : 'site'),
(it's copy&paste from Makefile.PL/Build.PL)
What is the catch? The issue is with Perl-s packaged from your $favourite Linux distribution and installing modules via `cpan -i`. Those above lines force module installation to put files directly where the distribution puts files. In my case it's "/usr/share/perl/5.10/". This works fine until "Sunday" comes and there is a security bug fix for Perl. (everyone is fixing security bugs on his systems, isn't he?) Suddenly some (the manually upgraded ones) of the core modules are overwritten by old packaged versions. If any other manually installed Perl module or a local script has a dependency on higher version than there is in the packaged Perl, it will break. Ouuuuups.
Which ones are the core ones? Module::CoreList is our friend and on my system `perl -MModule::CoreList -le 'print join "\n", Module::CoreList->find_modules(qr/./);' | wc -l` say 616.
@YAPC::EU::2008 there was a talk called Perl in RPM-Land made by Dave Cross (davorg). At the end there was a discussion about installing via `cpan -i` or packaging modules. The result was a general agreement ;-) that people should use one or the other but never both at the same time. From what I've seen yesterday, it's just good to add that if `cpan -i` then better compile your own Perl and leave the system one for the system. It's hard to be really sure which module will require an upgrade of core-module as a dependency.
<quote>There's no point in acting all surprised about it. All the planning charts and demolition orders have been on display in your local planning department on Alpha Centauri for fifty of your Earth years, so you've had plenty of time to lodge any formal complaint and it's far too late to start making a fuss about it now.</quote>
I'm astonished to see that a lot of people using Linux are still using the cpan shell to install modules. Today, all respectable Linux distributions have a packaging system. When a module is available in the packaging system it should be used. This provides the best and easiest way for installing it and its dependencies.
When a module in the repository is missing or is to old all that's needed is to package it and to add it to a personal repository. Debian makes this very easy thanks to dh-make-perl and to reprepro. Redhat systems also have cpan2rpm and createrepo.
Re:CPAN shell is overrated
revdiablo on 2009-05-08T16:34:05
I agree with your basic premise, but the great thing about CPAN is that it's there when you need it. It's a lowest common denominator that you can fallback on when you're on an unfamiliar system, or one that doesn't provide a decent system for packaging perl modules (for example, Windows or OS X).
Installation throug CPAN shell is overrated
potyl on 2009-05-09T02:46:45
I also agree with you. This is why I specified in the comment that my opinion regards mostly Linux. As far as I know Windows and OS X have no "official" packaging mechanism. Under these OSes CPAN shell is more than a welcomed tool since installing modules would be nightmare without it.
Also the CPAN shell has many more features and usages than to install modules. The tool is needed and useful. What I deplore is that it is used all the time to install Perl modules. As Jozef exposed, this has some serious implications in systems that have their own packaging system (mainly Linux).
