On Wed, Apr 04, 2007 at 04:08:44PM +0200, Antoine Raillon wrote:
> >* Redoing the re-order @INC patch
> btw I see one question here, about g-cpan : I love this small tool but 
> it puts modules to vendor (as they're added by portage), so de-reversing 
> @INC in favor of site will probably push users to use CPAN/CPANPLUS 
> directly instead of g-cpan. Is it a problem ?

easily fixed with some eclass magic (we should get after your mentor to show you
the ins and outs of the eclasses - and for those of you not sure, I'm cab's
mentor :)

> That would be quite nice, but won't it be a problem with modules 
> requiring a specific version of libperl.so ? And if we also change 
> modules directories to match perl version, some modules may disappear to 
> the user's view while portage says they're here, isn't it ? I feel I'm 
> missing something here ;)

well, what i was trying to suggest (but this goes back to fiddling with @inc
patch) is to create an agnostic vendor directory that is devoid of perl version
information so that it's always /usr/lib/perl5/vendor_perl for portage installed
modules - but this is said without actually see if it would work with a slotted
perl. Might make more headaches than it's worth (at which point, what's the
point in a slotted perl if you have to rebuild everything multiple times perl
perl).

> 
> second point, is there a reason/policy in favor of a perl-config tool 
> more than an eselect module ?

nope. me grok bash, no grokie grok eselect :)


> ++,
> cab
> 
> -- 
> gentoo-perl@g.o mailing list
> 

-- 

-----o()o----------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net 
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
-----o()o----------------------------------------------

Hi, I'm a .signature virus! Please copy me in your ~/.signature.