Re: /usr/local and @INC
* Russ Allbery [Sat, 22 Mar 2008 10:02:25 -0700]:
> Adeodato Simó <firstname.lastname@example.org> 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.
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”