Gentoo Archives: gentoo-perl

From: Michael Higgins <mhiggins@×××××××××××××.com>
To: gentoo-perl@l.g.o
Subject: RE: [gentoo-perl] Big Perl Packages and g-cpan
Date: Wed, 14 Mar 2007 21:46:21
Message-Id: 00f101c76682$5b588ce0$6564a8c0@TBG.local
In Reply to: Re: [gentoo-perl] Big Perl Packages and g-cpan by Michael Cummings
> -----Original Message----- > From: Michael Cummings [mailto:mcummings@g.o] > > On Wed, 21 Feb 2007 13:38:04 -0800 > "Michael Higgins" <mhiggins@×××××××××××××.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> 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@×××××××××××××.com -- gentoo-perl@g.o mailing list


Subject Author
Re: [gentoo-perl] Big Perl Packages and g-cpan Michael Cummings <mcummings@g.o>