1 |
On Mon, 2006-01-09 at 21:19 +0200, Yuval Yaari wrote: |
2 |
> Ooh, you're slotting perl? :) |
3 |
> I recall a conversation where I suggested slotted perl and you told me |
4 |
> it's nearly impossible... :-) |
5 |
|
6 |
and i officially eat crow ;) (and it was near impossible...or so it |
7 |
seemed...) |
8 |
|
9 |
> I just have to quote you on this one: "it's always been my opinion that |
10 |
> it would be far more trouble than its worth" (sorry! had to!). |
11 |
> So I'll start by saying I'm REALLY glad you're experimenting with it. |
12 |
> |
13 |
no doubt about it - if this went 'real' the transition would be horrible |
14 |
for people. ("yes, please unmerge your current libperl and perl, ignore |
15 |
the warnings from portage that your breaking your box") |
16 |
|
17 |
|
18 |
|
19 |
> I didn't think about having both threaded and non-threaded perl (but |
20 |
> this could be so cool...), only different versions of perl. |
21 |
> A few things I've been thinking about: |
22 |
> |
23 |
hey, in for a penny, in for a pound :) ideally, even if slotting doesn't |
24 |
happen, i think that this approach to the threaded/nonthreaded might be |
25 |
worth migrating over. |
26 |
|
27 |
> - What exactly happens when someone emerges a dev-perl/* ebuild..? |
28 |
> Will it be installed for each perl version? Shared between all perl |
29 |
> versions (might cause problems)? |
30 |
> |
31 |
no, only for the currently 'active' perl. i saw the same -dev |
32 |
conversation your probably thinking of regarding python (or was it |
33 |
ruby?) modules, but i don't think that's entirely feasible. you'd have |
34 |
to be sure to rebuild every dependant module for both perl's, which in |
35 |
the end would be a lot of duplicated pm's out there (number of perl's |
36 |
times 2 if you have threaded enabled). ick. on my test laptop, its |
37 |
pretty much normal fair - if 5.8.6 is active, everything plops under |
38 |
there, if 5.8.7 is active, etc.. |
39 |
|
40 |
> - Every module's ebuild should know what perls it can run under... |
41 |
> |
42 |
this actual scenario has yet to come up though...most of the perl |
43 |
version problems i am aware of (and that doesn't say much :) has to do |
44 |
with modules trying to compile under extremely old perl versions. |
45 |
|
46 |
> - ..."After emerging Test-Harness, 2.56 stays at the top of the stack |
47 |
> at all times" is nice, but think of situations when the newer version of |
48 |
> a module can't work with older versions of perl. OUCH. |
49 |
> |
50 |
back to previous comment - we don't have any of those perl's in portage. |
51 |
|
52 |
> - I'd personally like the ability to emerge a module for a specific |
53 |
> version of perl. Since each perl version has its own Config.pm, each |
54 |
> perl could have its own @INC, and possibly a "shared" lib between all perls. |
55 |
> |
56 |
actually started to tackle that almost...you'll notice there's room for |
57 |
a /usr/$(get_libdir)/perl5/gentoo dir to install into now (instead |
58 |
of /etc/perl iirc, or maybe it was /usr/local/perl that it replaced), |
59 |
the original notion being just that. Only problem is that since all of |
60 |
that is handled at the eclass level, and the eclass needs to remain |
61 |
universal, i didn't want to break one version( of ebuild) for the sake |
62 |
of another. also, this doesn't solve the problem of ebuilds that build |
63 |
into $ARCHNAME, or into $LIB-threads (if threads are enabled) - those |
64 |
would still not be cross compatible, plus you might have real problems |
65 |
trying to use .so's generated against libperl5.8.7 with perl5.8.6. |
66 |
|
67 |
like i said, its an experiment :) and patches are always welcome, if i'm |
68 |
wrong on any of my assumptions (yeah, i know what happens when you |
69 |
assume..) just let me know :) |
70 |
|
71 |
~mcummings |