Re: @INC changes on Perl upgrade
On Thu, Feb 16, 2006 at 01:52:12PM -0800, Bill Moseley wrote:
>I had Class::DBI installed from the deb package. I then upgraded via
>CPAN (yes, mixing package systems is a mistake).
>
>So, I had CDBI in two places:
>
> /usr/local/share/perl/5.8.7/Class/DBI.pm
> /usr/share/perl5/Class/DBI.pm
>
>Now after upgrading Perl, @INC looks like this:
>
> /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
> /usr/local/lib/perl/5.8.7
> /usr/local/share/perl/5.8.7
> /usr/local/lib/perl/5.8.4
> /usr/local/share/perl/5.8.4
> /usr/local/lib/perl/5.8.2
> /usr/local/share/perl/5.8.2
> /usr/local/lib/perl/5.8.1
> /usr/local/share/perl/5.8.1
> /usr/local/lib/perl/5.8.0
> /usr/local/share/perl/5.8.0
>
>So that upgrade now favors /usr/share/perl5 over /usr/local/share/perl/5.8.7.
>
>That is, before the upgrade I was using the local copy:
>
> /usr/local/share/perl/5.8.7/Class/DBI.pm
>
>and now after the upgrade I'm now using the older version:
>
> /usr/share/perl5/Class/DBI.pm
>
>Shouldn't locally installed modules be loaded over the modules in
>/usr/share?
No. This is the intended, and documented[0] behaviour.
The structure of @INC is intended to allow a *limited* overriding of
core/vendor modules by the site directories. It is also intended to
deal mainly with upgrades between stable releases.
Old site directories are listed last (which is where there are located
by default upstream) to avoid potential problems where CORE or packaged
modules break due to an older package being installed in the site
directories leading to difficult to locate bugs.
Typically, a local admin installs a package to the site dirs because:
* It is not available in either CORE or vendor at the time, or
* a newer version is required than is provided by CORE/vendor (long
stable release cycles).
The theory is that at time of upgrading to the next stable release, the
CORE or vendor versions will be the most current, and should be
preferred over the module installed locally.
These assumptions do not necessarily hold for people tracking unstable,
although generally should not be *too* far off the mark if the perl
module packagers are following upstream releases relatively promptly.
In your specific case, I note that libclass-dbi-perl is "out of date"
since the maintainer is waiting for upstream to release a stable
version[1] before updating the package. Suggest you simply un-install
libclass-dbi-perl.
--bod
[0] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-perl.html#s-paths
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329511#msg10
Reply to: