Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-perl
Navigation:
Lists: gentoo-perl: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-perl@g.o
From: Antoine Raillon <cab@g.o>
Subject: Re: [RFC] Some thoughts on the next release of perl
Date: Wed, 04 Apr 2007 16:08:44 +0200
Michael Cummings a écrit :
> * 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 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 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.
>
>   
That would be quite nice, but won't it be a problem with modules 
requiring a specific version of libperl.so ? 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


Replies:
Re: [RFC] Some thoughts on the next release of perl
-- Michael Cummings
References:
[RFC] Some thoughts on the next release of perl
-- Michael Cummings
Navigation:
Lists: gentoo-perl: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [RFC] Some thoughts on the next release of perl
Next by thread:
Re: [RFC] Some thoughts on the next release of perl
Previous by date:
Re: [RFC] Some thoughts on the next release of perl
Next by date:
Re: [RFC] Some thoughts on the next release of perl


Updated Jun 17, 2009

Summary: Archive of the gentoo-perl mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.