Re: /usr/local and @INC
On Mon, Mar 24, 2008 at 5:27 AM, Adeodato Simó <dato@net.com.org.es> wrote:
> Aha. But what about local modules with changes to existing modules that
> will not be included? If I want to put a module that should override
> perl 5.8, 5.8.8, 5.10, ... where should I put it? That's the use case I
> was initially referring to.
The rationale behind the ordering of @INC is to allow packaged modules
(vendor) to override modules in CORE, and for user-installed modules
(site) to trump both. There is some discussion of this in the Debian
Perl Policy.
Site directories contain version, even for arch-independent modules
primarily so that packages installed via CPAN will be "obsoleted" by
(hopefully) newer versions when a new perl package version is
released. This was a deliberate choice to reduce the chance of an
older locally-installed module introducing random breakage in CORE
modules which expect a specific API.
There is also a not particularly well documented
/usr/local/lib/site_perl directory, in which you can stuff arch-indep
modules which does not contain version-specific subdirectories (see
Bug#87831), although the ordering of this directory is such that it
will not override CORE modules (the intent is for locally produced
rather than CPAN modules here).
Having /etc/perl at the start of the list is mostly for
configuration-like modules (such as for CPAN) on systems where /usr
may not be writable.
If you have site-specific requirements which don't fit into these
categories, you should probably consider setting PERL5LIB in
/etc/environment, or perhaps creating /etc/perl/site_policy.pm which
has "use lib '/some/where'" and adding "use site_policy" to your code.
This is perhaps something which could be proposed to upstream if
there was sufficient intrerest--an automagic use of site_policy (which
could include more than just @INC twiddling).
--bod
Reply to: