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 ?
email@example.com mailing list