I recently installed Fedora 11 on my laptop. Checking the perl there, I found that INC includes /usr/local,   Compiled at Jun  8 2009 09:21:11   @INC:     /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi     /usr/local/lib/perl5/site_perl/5.10.0     /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi     /usr/lib/perl5/vendor_perl/5.10.0     /usr/lib/perl5/vendor_perl     /usr/lib/perl5/5.10.0/i386-linux-thread-multi     /usr/lib/perl5/5.10.0     /usr/lib/perl5/site_perl This seems like a bad idea to me, its unnecessary to use both /usr/lib and /usr/local/lib, and just invites potential confusion wrt compile-time options and binary compatibility. ( I assume that not all compile-time variations that would install to a particular directory, say /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi are are guaranteed to be ABI compatible ) So I opened a (low-prio) bug ticket: https://bugzilla.redhat.com/show_bug.cgi?id=508504 The ticket was re-assigned to Stephen Kasal, who hangs out here sometimes, so perhaps we can reach a consensus on best practice, and the severity of the bug, and he'll read it here ?

2009/7/7 Jim Cromie < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it : I recently installed Fedora 11 on my laptop. Checking the perl there, I found that INC includes /usr/local, /usr/local is traditionally for user stuff, so I'm not overly shocked to see site_perl there. Well, its certainly not a major flaw, and the likelihood of my own builds interfering with a i386-linux-thread-multi are small (well, none), but surely its something that is well handled by PERL5LIB, etc.. Moreover, I dont think its there for back-compatiblity reasons; at least one older fedora release (the 5.8.6 one) did not have /usr/local. That said, the DarkPAN matters

2009/7/7 Jim Cromie < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it : I recently installed Fedora 11 on my laptop. Checking the perl there, I found that INC includes /usr/local, /usr/local is traditionally for user stuff, so I'm not overly shocked to see site_perl there. Well, its certainly not a major flaw, and the likelihood of my own builds interfering with a i386-linux-thread-multi are small (well, none), but surely its something that is well handled by PERL5LIB, etc.. Moreover, I dont think its there for back-compatiblity reasons; at least one older fedora release (the 5.8.6 one) did not have /usr/local. That said, the DarkPAN matters I don't see the problem.  Putting site_perl over in /usr/local is a reasonable strategy, since it's for stuff *not* installed as part of the Fedora distribution. That said, various distributors, including Fedora (and RedHat before that) have often changed @INC in significant ways from the INSTALL defaults.  I don't think there's anything p5p can or should do about it.

2009/7/7 Jim Cromie < This e-mail address is being protected from spam bots, you need JavaScript enabled to view it : I recently installed Fedora 11 on my laptop. Checking the perl there, I found that INC includes /usr/local, /usr/local is traditionally for user stuff, so I'm not overly shocked to see site_perl there. Well, its certainly not a major flaw, and the likelihood of my own builds interfering with a i386-linux-thread-multi are small (well, none), but surely its something that is well handled by PERL5LIB, etc.. Moreover, I dont think its there for back-compatiblity reasons; at least one older fedora release (the 5.8.6 one) did not have /usr/local.  That said, the DarkPAN matters I would guess it is there for FHS-compliance: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY