Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-perl
Lists: gentoo-perl: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-perl@g.o
From: Michael Cummings <mcummings@g.o>
Subject: Re: Big Perl Packages and g-cpan
Date: Fri, 2 Mar 2007 22:19:48 -0500
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
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.



Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on 
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E

Hi, I'm a .signature virus! Please copy me in your ~/.signature.
signature.asc (PGP signature)
RE: Big Perl Packages and g-cpan
-- Michael Higgins
Re: Big Perl Packages and g-cpan
-- Michael Cummings
RE: Big Perl Packages and g-cpan
-- Michael Higgins
Lists: gentoo-perl: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
RE: Big Perl Packages and g-cpan
Next by thread:
RE: Big Perl Packages and g-cpan
Previous by date:
Perl ebuilds needing updates
Next by date:
Re: Big Perl Packages and g-cpan

Updated Jun 17, 2009

Summary: Archive of the gentoo-perl mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.