Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#19136 - [perl] double entry in @INC

Attached to Project: Arch Linux
Opened by Caleb Cushing (xenoterracide) - Saturday, 17 April 2010, 15:43 GMT
Last edited by Kevin Piche (kpiche) - Wednesday, 19 May 2010, 02:37 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Kevin Piche (kpiche)
Francois Charette (Firmicus)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

as you can see /usr/share/perl5/vendor_perl is listed twice I don't know why but I'm pretty sure it shouldn't be. I doubt it actually causes problems

perl -V

Built under linux
Compiled at Oct 3 2009 16:21:21
@INC:
/usr/lib/perl5/site_perl/5.10.1
/usr/share/perl5/site_perl/5.10.1
/usr/lib/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib/perl5/core_perl
/usr/share/perl5/core_perl
/usr/lib/perl5/current
/usr/lib/perl5/site_perl/current
This task depends upon

Closed by  Kevin Piche (kpiche)
Wednesday, 19 May 2010, 02:37 GMT
Reason for closing:  Fixed
Additional comments about closing:  @INC was fixed in 5.12.0-2.
Comment by Francois Charette (Firmicus) - Monday, 19 April 2010, 13:54 GMT
Thanks for spotting this. Seems to come from our setting "privlib" and "vendorlib" to the same path during configuration.
This is more an esthetic problem than anything else, but we'll try to avoid it with the next release (Perl 5.12.0 is out since a couple of days.)
@Kevin: I have already a PKGBUILD for 5.12.0 which I will email you for review and testing :)
Comment by Kevin Piche (kpiche) - Thursday, 06 May 2010, 03:11 GMT
privlib and vendorlib are not the same in the PKGBUILD. Looks like we'll still need the inc-blah.patch to remove the extra directories in INC.

Never mind adding -Dinc_version_list=none takes care of the versioned directories.
Comment by Caleb Cushing (xenoterracide) - Thursday, 06 May 2010, 10:49 GMT
I haven't noticed this in my perl5.12 build so maybe it'll just get fixed when migrating to that? (course thus far that perl is broken)
Comment by Kevin Piche (kpiche) - Sunday, 09 May 2010, 03:48 GMT
The perl 5.12 I built had extra directories appended to @INC. The Configure script likes to add directories for pervious versions into @INC. I haven't seen any problems with perl yet - "make test" had only one test failure which seems pretty good. Could you elaborate?
Comment by Caleb Cushing (xenoterracide) - Sunday, 09 May 2010, 14:29 GMT
I've had more than 1 test failure. At this point I'm willing to accept that it could be something with my system causing it. I'm supposed to be reinstalling right now... but one of my new drives is getting RMA'd. However the easiest way to see if you're having my problems is to install CPANPLUS::Dist::Arch (either from aur or cpan) then try to cpan2aur -d cpanp package. That was segfaulting. Also cpanp -o was outputting warnings about an IO::Compress module. I /think/ adding -Dinc_version_list=none \ to the configure will prevent it from picking up old perls... but just cleaning out old perl install directories will work too.
Comment by Kevin Piche (kpiche) - Sunday, 16 May 2010, 03:14 GMT
I think it may be your system since cpanp -o works for me. Perhaps the segfaulting module has an *.so file that needs to be rebuild for 5.12.0?
Comment by Caleb Cushing (xenoterracide) - Sunday, 16 May 2010, 06:59 GMT
not that I've been able to determine... because I went through and removed everything down to things built with core. but it does seem to be environmental... I was unable to reproduce on the system that I setup at school. This is very annoying for me... trying to get this system migrated to a new install but I can't get grub to boot the raid :(.
Comment by Kevin Piche (kpiche) - Wednesday, 19 May 2010, 02:37 GMT
The @INC order is site, vendor, core so perhaps a module in site or vendor doesn't work with the new core. My last suggestion is checking for packages for the wrong architecture - I did this once and funny things can happen. I'm going to close this since it seems to be localized to you. :D

Loading...