Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

  (email not shown publicly)
AOL IM: MichaelSchwern (Add Buddy, Send Message)

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Tuesday July 07, 2009
06:29 PM

perl/vendor/site explained

[ #39246 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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.

  • 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 (whic

    The new Strawberry Perl for Windows has been released! Check for it.