1 |
* libperl.a vs libperl.so - Policy dictates that whenever possible, if a library |
2 |
can be made either way, that both should be generated and provided for those |
3 |
apps that need the static library to build against. Up till now, |
4 |
sys-devel/libperl has built the dynamic library, and dev-lang/perl has built |
5 |
the static library as it built perl (and thereby linked perl against the |
6 |
static). I'd like to suggest we reverse this process - let sys-devel/libperl |
7 |
build the static library for those that need it, but build the dynamic library |
8 |
alongside perl. The benefits here would be a smaller footprint for perl, and |
9 |
less hassle if someone rebuilds perl with new use flags (such as ithreads). |
10 |
|
11 |
* Redoing the re-order @INC patch - I've had discussions lately with folks, both |
12 |
on this list and in bugs, about the order we alter the @INC in. Our reverse |
13 |
@INC patch sets the order to vendor->site->core. For Gentoo provided modules, |
14 |
this means that any modules we provide override anything else. However, there |
15 |
are a growing number of users that prefer/need to use CPAN directly, which |
16 |
installs modules to site, meaning our ebuilds override those modules. In a |
17 |
perfect world this would be acceptable, except that if you're using CPAN |
18 |
directly, that means you have need of the module *now* - but the required qa |
19 |
periods for ebuilds (which I'm not arguing against) mean that it will be at |
20 |
least 30 days until we have a new module marked stable, assuming your arch is |
21 |
even in the list and we're on the ball (which I know I haven't always been to |
22 |
say the least). Part of this reordering would be to also reverse the order of |
23 |
how vendor/site, so that we @INC would go (for example): |
24 |
|
25 |
/usr/lib/perl5/vendor_perl |
26 |
/usr/lib/perl5/vendor_perl/5.8.8 |
27 |
/usr/lib/perl5/vendor_perl/5.8.8/i686-linux |
28 |
|
29 |
for vendor (same for site_perl). The rationale being to try and keep things |
30 |
as version agnostic as possible. This coupled with my previous bullet |
31 |
(libperl.so) and my next thought (slotting perl) would, at least in theoryand |
32 |
completely untested and unconfirmed, mean that so long as the |
33 |
libperl.so.<version> that the module was built against still exists, then perl |
34 |
should be able to continue to load most of the modules. We might still need to |
35 |
do a little perl-cleaner action, but it wouldn't be nearly as painful as it |
36 |
has been in the past. |
37 |
|
38 |
* Slotted perl - I know this was a quest of yuval's for some time, not sure what |
39 |
if any progress has been made (yuval?). My train of random thought on this is |
40 |
that perl binaries/scripts would install to |
41 |
/usr/$(get_libdir)/perl5/$(perl_version)/bin, and we would generate a |
42 |
perl-config tool, akin to (and possibly ripped from) the java-config tool |
43 |
where you could select which perl was your active perl. This would mean |
44 |
installing libperl.so to its normal location, which is actually under |
45 |
/usr/$(get_libdir)/perl5/($perl_version)/$(arch)-linux/CORE and using the |
46 |
perl-config tool to link it. |
47 |
|
48 |
|
49 |
I know that I've brought these thoughts up before, and even played with them a |
50 |
bit, and never made any real progress. But with the next release of perl looming |
51 |
ever closer on the horizon, I'd like to see the upgrade process go much more |
52 |
smoothly for our users (this last bit directed at the devs on the list, but |
53 |
hopefully the rest of you won't be offended by the sentiment). perl-cleaner |
54 |
works (mostly)(sometimes)(as well as can be expected), but it would be ideal to |
55 |
only need such a tool in dire circumstances. Comments welcome :) |
56 |
|
57 |
~mcummings |
58 |
|
59 |
-- |
60 |
|
61 |
-----o()o---------------------------------------------- |
62 |
Michael Cummings | #gentoo-dev, #gentoo-perl |
63 |
Gentoo Perl Dev | on irc.freenode.net |
64 |
Gentoo/SPARC |
65 |
Gentoo/AMD64 |
66 |
GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E |
67 |
-----o()o---------------------------------------------- |
68 |
|
69 |
Hi, I'm a .signature virus! Please copy me in your ~/.signature. |