[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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).


Reply to: