Gentoo Archives: gentoo-perl

From: Michael Cummings <mcummings@g.o>
To: gentoo-perl@l.g.o
Cc: gentoo-perl@l.g.o
Subject: Re: [gentoo-perl] Experimental Perl
Date: Mon, 09 Jan 2006 19:31:42
Message-Id: 1136835085.14268.24.camel@sys947.dtic.mil
In Reply to: Re: [gentoo-perl] Experimental Perl by Yuval Yaari
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-perl] Experimental Perl Yuval Yaari <yyuval@××××××××××.com>