Hide Forgot
Description of problem: Perl looks for a module in directories more than once. For example it will look in /usr/local/share/perl5, for a file, then if not found it will look again. Version-Release number of selected component (if applicable): perl-5.10.1-116.fc13.i686 How reproducible: 100% Steps to Reproduce: 1. perl -V 2. 3. Actual results: @INC includes duplicates Expected results: The @INC directories should be unique Additional info: It would be nice to include /usr/local/lib/site_perl in the list.
I'm testing a new patch for this issue.
Next update will contain these paths: @INC: /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl5 /usr/share/perl5 /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/site_perl . I removed duplicates which can be removed. For example /usr/share/perl5 is here twice, because first time it is privlib and second time vendorlib. It can't be removed in this release because some modules could have troubles finding modules in path. Is it /usr/local/lib/site_perl still needed? It wasn't also in previous updates.
`repoquery --whatprovides '/usr/local/lib/site_perl/*'' does not return anything concluding Fedora does not need it.
(In reply to comment #3) > `repoquery --whatprovides '/usr/local/lib/site_perl/*'' does not return > anything concluding Fedora does not need it. This doesn't mean anything. /usr/local is supposed to contain files an admin of a system has locally installed on his system to override vendor files below /usr. Packaging-wise, this means /usr/local is "out of Fedora's packaging business" (Fedora must not package files into subdirectories below /usr/local), but it doesn't mean applications should not take directories below /usr/local into account. A classic example for such behavior is gcc. By default, it looks for headers into /usr/local/include before it looks into /usr/include.
I meant no official Fedora package does need it. Thus it's just matter of backward compatibility since we provide /usr/local/lib/perl5. I'd like to not remove any path in one Fedora release because of the compatibility.
I am not talking about removing a directory from the search list. That is a different issue. I am talking about not looking in a directory more than once.
(In reply to comment #6) > I am not talking about removing a directory from the search list. That is a > different issue. I am talking about not looking in a directory more than once. I can only repeat my answer from comment #2. It's not possible to cut it more than to this. The same path is there twice because it represent different macros for perl.
(In reply to comment #3) > `repoquery --whatprovides '/usr/local/lib/site_perl/*'' does not return > anything concluding Fedora does not need it. That misses the point. It's the best place for users to put locally created modules.
(In reply to comment #8) > (In reply to comment #3) > > `repoquery --whatprovides '/usr/local/lib/site_perl/*'' does not return > > anything concluding Fedora does not need it. > > That misses the point. It's the best place for users to put locally created > modules. For local modules we have /usr/local/lib/perl5. All other /usr/local/... paths are superflous.
perl-5.10.1-119.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/perl-5.10.1-119.fc13
perl-5.10.1-119.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/perl-5.10.1-119.fc13
perl-5.10.1-119.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.