Bug#95879: perl-base: contents of @INC

[Dominic Hargreaves]

Hi Julian,

I'm going over some (very!) old bug reports in perl and came
across this thread which never really reached a satisfactory
conclusion.

On Fri, May 18, 2001 at 06:41:38PM +0100, Julian Gilbey wrote:
> On Fri, May 18, 2001 at 02:12:16PM +1000, Brendan O'Dea wrote:
> > Of *course* I'm aware of that behaviour Julian, it was specifically
> > designed to work that way.
> > 
> > Not everyone dilligently checks that none of their locally installed
> > perl modules (yes, even arch-indep ones) shadows a newer version in the
> > perl core.
> 
> This is true.
> 
> > This setup is designed to allow people to do something like:
> > 
> >     perl -MCPAN -e "install Foo"
> > 
> > to get "Foo", or a newer version thereof installed.
> 
> Well thought out, I agree.
> 
> > >You're going against the important principle that local "settings" (in
> > >/usr/local) should take precedence over standard system "settings".
> > >I'm also bothered that a minor version upgrade is going to change the
> > >order of precedence.
> > 
> > Going against?  I've taken some great pains to allow both packaged
> > modules and local modules to override system ones.
> > 
> > The standard perl install, and the setup in all Debian perl packages
> > prior to the current 5.6.0-X packages was to have site_perl *below* the
> > core directories.
> > 
> > Is the situation you describe, that of say perl-5.6.1 overriding a
> > version of a module installed in /usr/local/*/perl/5.6.0 with an earlier
> > version *really* that common?
> 
> No, but there's a very different concern, where someone has installed
> a *modified* version of a standard module which does something
> slightly different from the standard one.  Why would they do something
> like that and not use their own module name?  Perhaps different config
> options or something equally silly.  Well, people are people, and
> that's essentially why I think this is potentially problematic.
> 
> > Recall that you can of course install to (or create local packages)
> > /usr/{lib,share}/perl5 or to any other directory and set
> > PERLLIB/PERL5LIB.
> 
> Of course they can; I'm just concerned that the order of precedence
> will change unexpectedly.  I'm not as bothered about old versions of
> stuff exclipsing newer ones; that comes with locally installed stuff.

I think this is a situation where it impossible to satisfy all
concerns at once, and given that the @INC being discussed has effectively
survived a decade in Debian, I'm inclined to close this bug now. Please
let me know if you still feel strongly that this should be doing
something different and I'll leave it open, although it may well
acquire a wontfix tag in that instance.

Cheers,
Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)