As part of answering a MakeMaker ticket I wrote out a fairly solid explanation of what the three different install locations mean for CPAN modules.
> (Personally I've always found the perl/site/vendor distinction and the
> triplicated set of directories to be fairly impenetrable :-), beyond
> that only 1 of the 3 at various times did something like I thought I
> wanted!)
Part of the problem is the whole philosophy is never fully explained. Part of it is that until 5.12 the default look up order is wrong.
Its pretty simple. Think of it like MacPorts or fink which doesn't control the entire operating system. You effectively have three managers working at the same time. You have the user installing things by hand. You have the package manager. And then there's the operating system.
In a flat layout they'll stomp all over each other. You might install an upgraded program from MacPorts and then have the next OS upgrade downgrade it again. The user might install the latest version from a tarball and then MacPorts installs an older version on top of it next upgrade.
"site" is what gets installed by the user, like /usr/local.
"vendor" is what gets installed by the package manager. /opt/local for MacPorts, /sw for fink.
"core" is what originally shipped with the operating system (or in Perl's case with Perl itself), like /usr.
You look in /usr/local first, then /opt/local, then /usr. In fact, that's how my PATH is set up. Unfortunately Perl itself incorrectly puts "core" first. Fortunately Debian (and I think Redhat now) fixes that. And 5.12 will finally fix it for all.
Packagers should be setting INSTALLDIRS=vendor. The CPAN shell should be using INSTALLDIRS=site. Nothing should be using perl/core. The broken lookup order complicates this because upgrades to dual-life CPAN modules have to go into core else they're not found, but Debian users don't have to worry about that.
Strawberry also breaks this
Alias on 2009-07-08T01:35:42
It's worth nothing that, at the moment, Strawberry does this all wrong.
The bundled modules we add to the default install go into site.
We're hoping to fix this for the October release, with the Strawberry-bundled extras (and dual-life updates) going into vendor instead of site.
Less breakage in Strawberry in July, hopefully.
I'll speak up and mention what is being done with the MSI (July) builds, which is subtly different, and hopefully closer to right.
The rule I used is: Module::CoreList is checked and what is updating core at installation build time is installed in core and what isn't is installed in site. Some of the dual-lifes do not do this on their own.
And yes, October 2009 will have the ability to use "INSTALLDIRS=vendor". Code has already started to be written. We're already making one horribly big change in July (which is why it went through 3 betas to make flipping sure it works)!
