On Wed, 21 Feb 2007 13:38:04 -0800
"Michael Higgins" <mhiggins@...> 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
> 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
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.
Michael Cummings | #gentoo-dev, #gentoo-perl
Gentoo Perl Dev | on irc.freenode.net
GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E
Hi, I'm a .signature virus! Please copy me in your ~/.signature.