Gentoo Archives: gentoo-perl

From: Michael Cummings <mcummings@g.o>
To: gentoo-perl@g.o
Cc: gentoo-perl@l.g.o
Subject: Re: [gentoo-perl] Experimental Perl
Date: Mon, 09 Jan 2006 19:31:45
In Reply to: Re: [gentoo-perl] Experimental Perl by Yuval Yaari
On Mon, 2006-01-09 at 21:19 +0200, Yuval Yaari wrote:
> Ooh, you're slotting perl? :) > I recall a conversation where I suggested slotted perl and you told me > it's nearly impossible... :-)
and i officially eat crow ;) (and it was near impossible...or so it seemed...)
> I just have to quote you on this one: "it's always been my opinion that > it would be far more trouble than its worth" (sorry! had to!). > So I'll start by saying I'm REALLY glad you're experimenting with it. >
no doubt about it - if this went 'real' the transition would be horrible for people. ("yes, please unmerge your current libperl and perl, ignore the warnings from portage that your breaking your box")
> I didn't think about having both threaded and non-threaded perl (but > this could be so cool...), only different versions of perl. > A few things I've been thinking about: >
hey, in for a penny, in for a pound :) ideally, even if slotting doesn't happen, i think that this approach to the threaded/nonthreaded might be worth migrating over.
> - What exactly happens when someone emerges a dev-perl/* ebuild..? > Will it be installed for each perl version? Shared between all perl > versions (might cause problems)? >
no, only for the currently 'active' perl. i saw the same -dev conversation your probably thinking of regarding python (or was it ruby?) modules, but i don't think that's entirely feasible. you'd have to be sure to rebuild every dependant module for both perl's, which in the end would be a lot of duplicated pm's out there (number of perl's times 2 if you have threaded enabled). ick. on my test laptop, its pretty much normal fair - if 5.8.6 is active, everything plops under there, if 5.8.7 is active, etc..
> - Every module's ebuild should know what perls it can run under... >
this actual scenario has yet to come up though...most of the perl version problems i am aware of (and that doesn't say much :) has to do with modules trying to compile under extremely old perl versions.
> - ..."After emerging Test-Harness, 2.56 stays at the top of the stack > at all times" is nice, but think of situations when the newer version of > a module can't work with older versions of perl. OUCH. >
back to previous comment - we don't have any of those perl's in portage.
> - I'd personally like the ability to emerge a module for a specific > version of perl. Since each perl version has its own, each > perl could have its own @INC, and possibly a "shared" lib between all perls. >
actually started to tackle that'll notice there's room for a /usr/$(get_libdir)/perl5/gentoo dir to install into now (instead of /etc/perl iirc, or maybe it was /usr/local/perl that it replaced), the original notion being just that. Only problem is that since all of that is handled at the eclass level, and the eclass needs to remain universal, i didn't want to break one version( of ebuild) for the sake of another. also, this doesn't solve the problem of ebuilds that build into $ARCHNAME, or into $LIB-threads (if threads are enabled) - those would still not be cross compatible, plus you might have real problems trying to use .so's generated against libperl5.8.7 with perl5.8.6. like i said, its an experiment :) and patches are always welcome, if i'm wrong on any of my assumptions (yeah, i know what happens when you assume..) just let me know :) ~mcummings


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