Red Hat Bugzilla – Bug 178688
Poor choice of build option -Dinc_version_list
Last modified: 2007-11-30 17:07:22 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Description of problem: The choice to build perl with -Dinc_version_list=5.8.4 5.8.3 5.8.2 5.8.1 5.8.0 is unbelievably bad. a) It causes a screenful of spew regarding @INC on error, masking any meaningful output b) It can cause unnecessary filesystem traversal which seriously penalizes normal usage, see: http://www.perl.com/pub/a/2005/12/21/a_timely_start.html The only work arounds are quite unpleasant: i) do a custom compile (either to use a proper @INC, or to upgrade to 5.8.7 for sitecustomize.pl) ii)symlink the other bogusly included version library directories (though this might cause other problems) On the other hand, annyone worried about backwards compatability could simply set PERL5LIB (see perlrun for more information). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. 2. 3. Additional info:
Sorry, but we undertake to support modules for every perl version in each RHEL version, particularly in supporting upgrade from RHEL-3 (perl-5.8.0) - a perl module installed under RHEL-3 must still work after upgrade to RHEL-4 . Startup time consumed by module search path searches can be minimised by placing 'BEGIN { @INC=...; }' in perl scripts that require a fast startup time. If you're sure you have no modules under unused perl version directories, remove those directories. The time taken for module search patch traversal is in any case minimal. So this is being closed as 'NOTABUG'.
And yet upgraded users could set @INC explicitly as you would have non-legacy users do, or use the inherent legacy support option I listed of PERL5LIB. "Removing directories" is a no-op because these directories don't exist, but are still in the binary's @INC. The question is not of the *perl module* working, that's nonsensical, but of the code which uses it being able to find the module. The time is *not trivial*, see the aforementioned article, or recent thread on the DateTime mailing list. And there is also the other issue of message dumping. If you are still so eager to dismiss this as NOTABUG (I agree, it's not, it's a poor implementation decision... exacerbated by some unfortunate choices in perl's handling of @INC) then *at least* pay attention and do not do this when RHEL ends up using perl 5.8.7 or later. In that case, if you still will not use PERL5LIB, make use of sitecustomize.pl which is user customizable; at which point the package preinstall scripts ought to check for existance of old site_perl and Do The Right Thing. Because perl -Mnonesuch Can't locate nonesuch.pm in @INC (@INC contains: /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .). BEGIN failed--compilation aborted. Is too much spew.