Red Hat Bugzilla – Bug 484053
@INC does not include /usr/lib/perl5/site_perl
Last modified: 2009-02-20 14:02:25 EST
Description of problem:
De ja vu from F9 (Bug 457771), '/usr/lib/perl5/site_perl' is again not in @INC for perl. This is a very venerable location for people to put their site modules - correct or not, and a lot of automated build systems put them there automagically. Fedora really needs to support this, even if it's not "best".
After talking with others on IRC I was asked to file a bug. Apologies if it's a dupe, I couldn't find anything for F10 that was similar.
Like I said in 457771, /usr/lib/perl5/site_perl/ was in never in @INC in any Fedora perl package. Arguably, anything that ignores the setting of sitelib in perl (set to /usr/local/lib/perl5/site_perl/5.10.0) is broken.
With that said, my only real concern about adding /usr/lib/perl5/site_perl/ to @INC is any performance hit from having more directories to trawl through.
Running or perl -V on a few dozen systems: FC1, FC2, FC4, FC5, FC6, FC7, FC8, F9, RHEL3 and RHEL4 all have /usr/lib/perl5/site_perl listed.
The largest problem with relying on sitelib is that it's a moving target. Upgrade a perl and *poof* new sitelib. That creates havoc with automatic build or deployment systems, because now you have multiple versions of the same mods out there. Yes, the @INC is ordered such that the newest should be loaded first, but it's very messy.
Regarding @INC performance, every upgrade of perl significantly increases (near-doubles, the first time) the size of @INC- Below is the list for an RHEL4 box.
[soacahtoa ~]# perl -e 'print join("\n",@INC);' | wc -l
If this is a "won't fix", that's fine. It was fixed in F9, and I was hoping for the same for F10.
I stand corrected. :)
As to RHEL4, it was bad because we had a metric TON of stuff in @INC back in those days.
In Fedora, we've trimmed way back on that, for example, in rawhide:
[spot@velociraptor devel]$ perl -e 'print join("\n",@INC);' | wc -l
That said, I'm inclined to keep this directory as otherlibs (and ONLY this directory), given its historical precedence. The perl package wouldn't create or own it.
A perfect solution, Tom. Thanks in advance for this.
A few details:
(In reply to comment #2 by Matthew)
> Running or perl -V on a few dozen systems: FC1, FC2, FC4, FC5, FC6, FC7, FC8,
> F9, RHEL3 and RHEL4 all have /usr/lib/perl5/site_perl listed.
In these releases, the variable "sitelib" for perl's Configure was set to (or defaulted to) $prefix/lib/perl5/site_perl/$version.
Then the Configure script modified that path by decrementing the version several times and byt removing the version suffix and added all of those after sitelib.
That's how /usr/lib/perl5/site_perl got there.
(In reply to comment #3 by spot)
> That said, I'm inclined to keep this directory as otherlibs (and ONLY this
> directory), given its historical precedence.
The "historical precedence" is in fact this:
- it gets into @INC in default configuration of upstream perl (if prefix=/usr, I mean)
- it was in @INC up to Fedora 8.
But, for example, Debian doesn't seem to be conservative enough: I visited a random debian installation, and @INC does not contain /usr/lib/perl5/site_perl.
(In reply to comment #3)
> [...] to keep this directory as otherlibs [...]
One more note: if this directory were in otherlibs, it would end up at the end of @INC.
Consequently, if a module were both provided by a Fedora package and installed under /usr/lib/perl5/site_perl, the Fedora version would override the other one, no matter which of them is newer.
This is a difference from sitelib, which goes first into @INC (together with sitearch), so the sitelib modules override the vendor-provided ones.
Matthew, with this in mind, is adding to otherlibs still a perfect solution?
(In reply to comment #6)
> (In reply to comment #3)
> > [...] to keep this directory as otherlibs [...]
> One more note: if this directory were in otherlibs, it would end up at the end
> of @INC.
> Consequently, if a module were both provided by a Fedora package and installed
> under /usr/lib/perl5/site_perl, the Fedora version would override the other
> one, no matter which of them is newer.
> This is a difference from sitelib, which goes first into @INC (together with
> sitearch), so the sitelib modules override the vendor-provided ones.
> Matthew, with this in mind, is adding to otherlibs still a perfect solution?
Stepan- Thank you for checking. This would be perfectly fine for the cases I'm most concerned with, which is build-and-deployment software placing modules in a consistent location not variable by version number. These modules are generally never installed from Fedora, CPAN, etc. where "standard" lib rules would be the norm. Thanks again for the forethought to confirm this!
Tom "spot" Callaway has comitted the change to F-10 and rawhide, it'll appear in F-10 Updates soon.
Please keep in mind that this is a Fedora specific feature, not portable to other Perl ports.
For example, /usr/lib/perl5/site_perl is not in @INC on Debian 4.0. (Debian @INC contains directory /usr/local/lib/site_perl to provide backward compatibiloty with early Debian's perl.)
It's always best to use perl -V:sitelib, e.g.
eval $(perl -V:sitelib)
to get the right directory.
Agreed upon change was noticed today in an update of perl. Thanks again to all involved- Can be closed.
Ugh, bodhi didn't close this out or notify of the update. Closing.