Gentoo Archives: gentoo-perl

From: Antoine Raillon <cab@g.o>
To: gentoo-perl@l.g.o
Subject: Re: [gentoo-perl] [RFC] Some thoughts on the next release of perl
Date: Wed, 04 Apr 2007 14:09:10
In Reply to: [gentoo-perl] [RFC] Some thoughts on the next release of perl by Michael Cummings
Michael Cummings a écrit :
> * libperl.a vs - Policy dictates that whenever possible, if a library > can be made either way, that both should be generated and provided for those > apps that need the static library to build against. Up till now, > sys-devel/libperl has built the dynamic library, and dev-lang/perl has built > the static library as it built perl (and thereby linked perl against the > static). I'd like to suggest we reverse this process - let sys-devel/libperl > build the static library for those that need it, but build the dynamic library > alongside perl. The benefits here would be a smaller footprint for perl, and > less hassle if someone rebuilds perl with new use flags (such as ithreads). >
Agree. not really my domain but I can't think of any problems if we reverse this one.. moreover it seems a bit more logical to me ;)
> * Redoing the re-order @INC patch
If I summarize we'll have site->vendor->core, +versionning of everything ? Seems quite fine to me. Plus with the project i'm working on with Michele right now, It'll probably be quite common to need CPAN modules directly for the users we target (either because of the stabilization delay, either because something is not in the tree). btw I see one question here, about g-cpan : I love this small tool but it puts modules to vendor (as they're added by portage), so de-reversing @INC in favor of site will probably push users to use CPAN/CPANPLUS directly instead of g-cpan. Is it a problem ?
> * Slotted perl - I know this was a quest of yuval's for some time, not sure what > if any progress has been made (yuval?). My train of random thought on this is > that perl binaries/scripts would install to > /usr/$(get_libdir)/perl5/$(perl_version)/bin, and we would generate a > perl-config tool, akin to (and possibly ripped from) the java-config tool > where you could select which perl was your active perl. This would mean > installing to its normal location, which is actually under > /usr/$(get_libdir)/perl5/($perl_version)/$(arch)-linux/CORE and using the > perl-config tool to link it. > >
That would be quite nice, but won't it be a problem with modules requiring a specific version of ? And if we also change modules directories to match perl version, some modules may disappear to the user's view while portage says they're here, isn't it ? I feel I'm missing something here ;) second point, is there a reason/policy in favor of a perl-config tool more than an eselect module ? ++, cab -- gentoo-perl@g.o mailing list


Subject Author
Re: [gentoo-perl] [RFC] Some thoughts on the next release of perl Michael Cummings <mcummings@g.o>