From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1HZ6Af-00060a-RE for garchives@archives.gentoo.org; Wed, 04 Apr 2007 14:09:10 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l34E8has024521; Wed, 4 Apr 2007 14:08:43 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l34E8fuD024479 for ; Wed, 4 Apr 2007 14:08:42 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id DE2086519C for ; Wed, 4 Apr 2007 14:08:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: 1.065 X-Spam-Level: * X-Spam-Status: No, score=1.065 required=5.5 tests=[AWL=1.065] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6KTKd6FKdFL for ; Wed, 4 Apr 2007 14:08:28 +0000 (UTC) Received: from gredin.net (gredin.net [213.246.63.66]) by smtp.gentoo.org (Postfix) with ESMTP id 53EB365180 for ; Wed, 4 Apr 2007 14:08:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gredin.net (Postfix) with ESMTP id 8F9F34B000C for ; Wed, 4 Apr 2007 16:08:24 +0200 (CEST) Received: from gredin.net ([127.0.0.1]) by localhost (gredin.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk21NjwbSwJW for ; Wed, 4 Apr 2007 16:08:13 +0200 (CEST) Received: from [10.0.0.103] (mtg95-1-82-233-25-227.fbx.proxad.net [82.233.25.227]) by gredin.net (Postfix) with ESMTP id 379404B000B for ; Wed, 4 Apr 2007 16:08:13 +0200 (CEST) Message-ID: <4613B16C.9080104@gentoo.org> Date: Wed, 04 Apr 2007 16:08:44 +0200 From: Antoine Raillon User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-perl@gentoo.org Reply-To: gentoo-perl@gentoo.org MIME-Version: 1.0 To: gentoo-perl@lists.gentoo.org Subject: Re: [gentoo-perl] [RFC] Some thoughts on the next release of perl References: <20070403114019.GA20273@paradox.datanode.net> In-Reply-To: <20070403114019.GA20273@paradox.datanode.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id l34E8hb9024521 X-Archives-Salt: 3d9fe3f1-51be-4016-b850-444419a4e943 X-Archives-Hash: 63974ca5c90e7e3dadcc9c1318b0623d Michael Cummings a =E9crit : > * libperl.a vs libperl.so - Policy dictates that whenever possible, if = a library > can be made either way, that both should be generated and provided fo= r 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 ha= s 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 dynami= c library > alongside perl. The benefits here would be a smaller footprint for pe= rl, and > less hassle if someone rebuilds perl with new use flags (such as ithr= eads). > =20 Agree. not really my domain but I can't think of any problems if we=20 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=20 ? Seems quite fine to me. Plus with the project i'm working on with=20 Michele right now, It'll probably be quite common to need CPAN modules=20 directly for the users we target (either because of the stabilization=20 delay, either because something is not in the tree). btw I see one question here, about g-cpan : I love this small tool but=20 it puts modules to vendor (as they're added by portage), so de-reversing=20 @INC in favor of site will probably push users to use CPAN/CPANPLUS=20 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 me= an > installing libperl.so 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. > > =20 That would be quite nice, but won't it be a problem with modules=20 requiring a specific version of libperl.so ? And if we also change=20 modules directories to match perl version, some modules may disappear to=20 the user's view while portage says they're here, isn't it ? I feel I'm=20 missing something here ;) second point, is there a reason/policy in favor of a perl-config tool=20 more than an eselect module ? ++, cab --=20 gentoo-perl@gentoo.org mailing list