@INC order?

[Stepan Kasal]

Hello,

> From perl-5.10.0-56.fc10:
> 
>   @INC:
>     /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi
>     /usr/lib/perl5/5.10.0
>     /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi
>     /usr/local/lib/perl5/site_perl/5.10.0
>     /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi
>     /usr/lib/perl5/vendor_perl/5.10.0
>     /usr/lib/perl5/vendor_perl
>     /usr/local/lib/perl5/site_perl
>     /usr/local/lib64/perl5/site_perl
>     /usr/lib/perl5/site_perl
>     .
> 
> I was under the impression that the search order (for Fedora Perl at
> any rate) was always site, then vendor, then core (the better to allow
> people to override core and their vendors with).  For F-10 (this build
> at any rate) it seems to be core, then part of site, then vendor, then
> the rest of site.
> 
> Can someone sanity check my thinking here?

I'd like correct a detail:
the current order is core, site, vendor, obsolete dirs.

What you call "rest of site" are previous incarnations of sitelib,
implemented using otherlibdirs.
1) /usr/local/{lib,%{_lib}}/perl5/site_perl
- These two (they are one on 32 bit archs) are to be removed soon
  (F-11), they were present only for a limited transition period.
2) /usr/lib/perl5/site_perl
- It has been promised that this obsolete sitelib will stay
  permanently, and that there will be no others to join it (see
  bz 484053).

> I'll file a bug if it seems sane :-)

I agree that "site, vendor, core" seems sane.  A quick check on a
Debian installation with perl-5.8.8 seems to indicate that they share
this idea.

> After poking around a bit, it looks like somewhere between F-8 and
> now @INC's order changed.

More poking shows that the change was implemented on Fedora by
perl-5.8.5-incorder.patch.  Version up to 5.8.5 and including some of
the releases of 5.8.5 followed the upstream order which always has
been  "core, site, vendor"

During the update to 5.10.0, this patch has been dropped, perhaps
unintentionally.

I've yet to check whether the patch is still present in latest Debian
builds; if yes, I'm all for including it again.

Have a nice day,
	Stepan Kasal