Gentoo Archives: gentoo-perl

From: Michael Cummings <mcummings@g.o>
To: gentoo-perl@l.g.o
Subject: Re: [gentoo-perl] Big Perl Packages and g-cpan
Date: Sat, 03 Mar 2007 03:20:14
In Reply to: RE: [gentoo-perl] Big Perl Packages and g-cpan by Michael Higgins
On Wed, 21 Feb 2007 13:38:04 -0800
"Michael Higgins" <mhiggins@×××××××××××××.com> wrote:

> > -----Original Message-----
> ... which is what I had to do just to get started. Why are so many > modules out of date? Why do I need virtuals in here? B/C otherwise > the keyword unmasking fails.
Because the x86 team hasn't unmasked any of these. Other arch's have, x86 is just behind on these. I know sparc and amd64 are pretty up to date, and even alpha stays pretty close to the curve, x86 is just slow. I think they prefer to have stable ticket requests to mark something, but with 666 modules (roughly) that's more hand holding than I think we're up to. FWIW, I just built Maypole using g-cpan-0.15_rc3, no problem.
> CPAN might choke eventually on the dependencies for a package like > this, but gcpan... fails with less information... gcpan logging > doesn't get you much error info.
Again, wish you could give something more than "gcan just chokes." If I can't dup it and can't see what you mean, I can't hope to fix it :) I have worked pretty hard in the more recent versions of g-cpan to resolve these dependency issues better, so any examples you can give of where it's failing would help out a ton.
> > gcpan's CPAN is way out of date too... I have to wonder, why? >
Because you never upgraded it...? ;) Seriously, we don't push CPAN as an ebuild because its not a dep of anything directly, and you can always g-cpan to bootstrap it to a newer version.
> Anyway, I'm just trying to figure out the best route for managing > these installations. CPAN is fine for me, as long as I don't... > what... emerge any modules?
Not sure what you're asking. If you don't want to use g-cpan, don't, that's pretty simple. g-cpan is for those folks that want some modules, but want them in the pretty portage architecture. if your more comfortable using cpan, use cpan. Just don't file bugs about it with us :) (duh, I know, but you'd be amazed)(or not)
> > It seemed to me at one point that it might be better, somehow, to > just find a way to patch CPAN to check and emerge any modules in the > portage tree... expect they are often out of date anyway. :( >
emerge how? cpan isn't about working with a package manager, any package manager.
> If one does move away from gcpan, I think one will need to unmerge > stuff from the tree and the overlay. At least, I've been bitten once > so far. I suppose they install in different locations? (No time to > check.) >
by default, cpan installs in site. we install in vendor. the reverse inc patch puts vendor at the top of the food chain, followed by site. So yes, anything you install by ebuild will trump a cpan install.
> Gosh, I wish I had more time to devote to this now. I'll look forward > to your reply.
You shouldn't - i'm tired and crabby and writing when i should be sleeping, which means i'm being a lot more rude than intended. ~mcummings -- -----o()o---------------------------------------------- Michael Cummings | #gentoo-dev, #gentoo-perl Gentoo Perl Dev | on 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.


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


Subject Author
RE: [gentoo-perl] Big Perl Packages and g-cpan Michael Higgins <mhiggins@×××××××××××××.com>