RE: [gentoo-perl] Big Perl Packages and g-cpan

["Michael Higgins" <mhiggins@banfieldgroup.com>]

> -----Original Message-----
> From: Michael Cummings [mailto:mcummings@gentoo.org] 
> 
> On Wed, 21 Feb 2007 13:38:04 -0800
> "Michael Higgins" <mhiggins@banfieldgroup.com> wrote:
> 
> > > -----Original Message-----
> <snip>
> > ... 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.

Hmm. So, it's incumbent on the user to unmask all potentially-used
ebuild-available modules? Or, when a module is released to CPAN, maybe a
ticket request needs to go automatically to the x86 folks?

Anyway, to try and fix the issues (and I don't care how, g-cpan -ned or
-less is fine), I've just scripted a bunch of additions to package.keywords
from eix reports of perl modules in portage, hopefully thereby unmasking
anything that might come up as a dependency and is already in portage. 

Now, if I can find a way to loop around g-cpan, simply automatically
unmasking anything it chokes on and making it try again...

Would you take a 'feature request' for that functionality? After all, they
are just perl modules.

And, what do I do when a module comes up in portage, but the latest masked
version is still not satisfying the dependencies? 

Editing an ebuild, wgetting the tarball, digesting and yet knowing it'd be
overwritten at the next sync is about where I got tired of the g-cpan
method. I'm not about wanting to make ebuilds. :(

> 
> FWIW, I just built Maypole using g-cpan-0.15_rc3, no problem.
> 

It wasn't a problem for me either, once I unmasked a bunch of modules. 

Would it be possible to do something like ACCEPT_KEYWORDS='~*' g-cpan blah
and avoid having to stop and unmask the dev-perl/??? and then stop again to
unmask the virtual/perl-???

Of course, that'd probably just be a problem next 'emerge world'. :(

> > 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 

I wasn't looking for a fix, but a workaround. I really don't expect a fix.
;-)

> 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.

Well, rather than get into it, consider this, from the catalystframework
overlay maintainer:

<quote http://forums.gentoo.org/viewtopic-t-419501-highlight-.html>
There's no ebuild in portage for most of the modules, and g-cpan doesn't
always behave well, This is particularly true when attempting the
installation of the Task::Catalyst meta-module, which pulls in almost
everything that is needed to write "serious" applications with Catalyst:
since it uses CPANPLUS, problems come around.
</quote>

So, I don't feel particularly off or unhelpful in saying 'it just chokes'.
"Problems come around" or "doesn't always behave well" are also apt
descriptions. 

Again, I was looking for a workaround, not a fix.

> 
> > 
> > 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.
> 

I never thought to do that. I assumed (reasonably, I think) g-cpan to be
some kind of a front-end to CPAN and, as such, should of course use the
latest version that it's, well, "front-ending". 

But I never looked 'under the hood' and don't expect to.

> > 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, 

Asking how to maintain a gentoo/portage system with up-to-date perl modules
added via CPAN, but still able to, say, install mod_perl so that it works
the 'gentoo way' but doesn't clobber my up-to-date CPAN-installed modules.

> 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. 

It's not that simple. If you emerge anything dependent on any perl module,
portage will install it and CPAN will choke on the out-of-date modules
portage installed, with infinite loops, no "upgrade" option.... aargh.

> Just don't file bugs about it with us :) (duh, I know, but 
> you'd be amazed)(or not)

I thought this was a "user" list. I didn't file a bug, I was hoping someone
out there using perl on gentoo (and maybe even reading the
appropriately-named gentoo-perl mailing list) could help make a transition
away from g-cpan.

My bad, I guess. :(

At this point, it seems the only way would be to put anything perlish in
package.provided to keep portage from emerging perl modules. I may have to
try that, barring some better advice.

> > 
> > 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.

That'd be the 'patch' part. ;-) Specific to portage users...??

> 
> > 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 

Ah, is this a gentoo-specific patch, then? I do find that whatever portage
installed is preempting my CPAN installs. I imagine this is by design, but,
how necessary is that, really?

> 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.
> 

I don't think you are being at all rude, especially if I was thinking of
contributing as a developer, or was being critical of your work.

But, I'm a lowly user who'd like a solution to a problem that still exists.
I don't feel qualified in any way to be a contributor. I think it's great
that you're working on this stuff. Sometimes folks just want to install a
module, or two, I suppose, and you've given them a nice tool for that.

. . .

Given what you've written, it would seem that removing the reverse @INC
patch would solve the problem as well, no? Portage could install whatever it
wanted, but my CPAN-installed module would be found first, right? 

Is this something I can tweak easily? Would doing that then allow me to use
CPAN and not have portage install older modules that are then found first in
@INC?

Anyway, the upshot is that I still don't have a working, easily replicable
installation of some perl-based application frameworks. It seems the
solution for, for example the catalystframework folk, was to make an ebuild.
And put up a starter list of modules to unmask.

I'm trying to go the g-cpan route again, should I find I need to install any
missing modules, just to see if there's any improvement in the process now
that I've unmasked everything I can find in the portage tree. 

Anyway, I hope you don't find my attempt at exacting language to be terse to
the point of rudeness. I am glad for your feedback so far and would love to
arrive at a solution.

I've been working on a development server, but my production server I'll be
working up soon. It'd just be nice to know that I can replicate an
installation with several perlish development frameworks comprised of
hundreds of perl modules without any hassle as described above. I don't care
what the workaround is.

On another point, with all the CPAN testing going on, is there not some way
to promote newer module versions automatically into portage? Why wouldn't a
good score from CPANTS or CPAN Testers be enough for the x86 devs to fix up
the ebuilds?

Cheers,

-- 
Michael Higgins
IS Specialist
The Banfield Group
Phone: (503) 352-3380 x205
Fax: (503) 352-3389
E-mail: mhiggins@banfieldgroup.com  


-- 
gentoo-perl@gentoo.org mailing list