Re: [gentoo-perl] Experimental Perl

[Michael Cummings <mcummings@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]

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 Config.pm, each 
> perl could have its own @INC, and possibly a "shared" lib between all perls.
> 
actually started to tackle that almost...you'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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]