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 |