| 1 |
Michael Cummings a écrit : |
| 2 |
> * libperl.a vs libperl.so - Policy dictates that whenever possible, if a library |
| 3 |
> can be made either way, that both should be generated and provided for those |
| 4 |
> apps that need the static library to build against. Up till now, |
| 5 |
> sys-devel/libperl has built the dynamic library, and dev-lang/perl has built |
| 6 |
> the static library as it built perl (and thereby linked perl against the |
| 7 |
> static). I'd like to suggest we reverse this process - let sys-devel/libperl |
| 8 |
> build the static library for those that need it, but build the dynamic library |
| 9 |
> alongside perl. The benefits here would be a smaller footprint for perl, and |
| 10 |
> less hassle if someone rebuilds perl with new use flags (such as ithreads). |
| 11 |
> |
| 12 |
Agree. not really my domain but I can't think of any problems if we |
| 13 |
reverse this one.. moreover it seems a bit more logical to me ;) |
| 14 |
> * Redoing the re-order @INC patch |
| 15 |
If I summarize we'll have site->vendor->core, +versionning of everything |
| 16 |
? Seems quite fine to me. Plus with the project i'm working on with |
| 17 |
Michele right now, It'll probably be quite common to need CPAN modules |
| 18 |
directly for the users we target (either because of the stabilization |
| 19 |
delay, either because something is not in the tree). |
| 20 |
btw I see one question here, about g-cpan : I love this small tool but |
| 21 |
it puts modules to vendor (as they're added by portage), so de-reversing |
| 22 |
@INC in favor of site will probably push users to use CPAN/CPANPLUS |
| 23 |
directly instead of g-cpan. Is it a problem ? |
| 24 |
> * Slotted perl - I know this was a quest of yuval's for some time, not sure what |
| 25 |
> if any progress has been made (yuval?). My train of random thought on this is |
| 26 |
> that perl binaries/scripts would install to |
| 27 |
> /usr/$(get_libdir)/perl5/$(perl_version)/bin, and we would generate a |
| 28 |
> perl-config tool, akin to (and possibly ripped from) the java-config tool |
| 29 |
> where you could select which perl was your active perl. This would mean |
| 30 |
> installing libperl.so to its normal location, which is actually under |
| 31 |
> /usr/$(get_libdir)/perl5/($perl_version)/$(arch)-linux/CORE and using the |
| 32 |
> perl-config tool to link it. |
| 33 |
> |
| 34 |
> |
| 35 |
That would be quite nice, but won't it be a problem with modules |
| 36 |
requiring a specific version of libperl.so ? And if we also change |
| 37 |
modules directories to match perl version, some modules may disappear to |
| 38 |
the user's view while portage says they're here, isn't it ? I feel I'm |
| 39 |
missing something here ;) |
| 40 |
|
| 41 |
second point, is there a reason/policy in favor of a perl-config tool |
| 42 |
more than an eselect module ? |
| 43 |
|
| 44 |
++, |
| 45 |
cab |
| 46 |
|
| 47 |
-- |
| 48 |
gentoo-perl@g.o mailing list |
Archives