Re: /usr/local and @INC

[Adeodato Simó <dato@net.com.org.es>]

* Russ Allbery [Sat, 22 Mar 2008 10:02:25 -0700]:

> Adeodato Simó <dato@net.com.org.es> writes:

> > If somebody could enlighten me about perl's search path (@INC), I'd be
> > grateful. The value of @INC in Debian seems to be:

> >   /etc/perl

> >   /usr/local/lib/perl/5.8.8
> >   /usr/local/share/perl/5.8.8

> >   /usr/lib/perl5
> >   /usr/share/perl5

> >   /usr/lib/perl/5.8
> >   /usr/share/perl/5.8

> >   /usr/local/lib/site_perl
> >   .

> > I don't understand why the paths under /usr/local have to be so
> > version-specific, whereas the /usr counterparts are more general.

> You'll find that if you have other versioned directories in /usr/local,
> they will also be added to the module path, but at the end.  The set of
> directories is discovered dynamically at runtime.  This offers the best
> handling of the case where you install a newer version of a core module in
> /usr/local, but then the next point release of Perl updates the same
> module.  The assumption is that a new point release of Perl will include a
> newer version of such modules.

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.

Thanks,

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
— Oh, George, you didn't jump into the river. How sensible of you! 
                -- Mrs Banks in “Mary Poppins”