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

[Michael Cummings <mcummings@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 7632 bytes --]

I know, I'm doing such a great job of responding in a timely fashion :) 

On Wed, Mar 14, 2007 at 02:47:26PM -0700, Michael Higgins wrote:
 
> 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?

No, it is not incumbent. Since this thread started (I know, there's only been a
few posts to it, but that still counts), I've worked with the x86 folks to bring
the keywords up to date for that platform. As a general rule, barring security
fixes and the like, something should be in the tree for 30-60 days before a
request to mark it stable can be filed. That said, I (and my fellow perl devs)
aren't perfect - its perfectly feasible and likely that we will miss modules
that are worthy of marking stable on your $arch (human volunteers and all that).
You are always welcome, as a user of Gentoo, to submit a bug requesting that
something go stable - if nothing else its a warm fuzzy that people are out there
and using stuff and actually in need of it (vs our guessing that folks are
trying stuff).

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

Believe me, this is a feature I have in mind for 0.16 (0.15 is too far out the
door for this kind of addition). My frame of thought is comparing your
ACCEPT_KEYWORD against the needed ebuild's KEYWORDS and making a copy in your
overlay if necessary. That and actually documenting this disparity between
what's keyworded in the tree and what g-cpan's keyworded....

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

um, done :)

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

gripe at us :) those automated emails that get sent are to remind us of what's
getting behind in the tree. We try to tackle them as often as possible - but
other things crop up (i'm done  giving excuses, don't worry)

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

eh? g-cpan shouldn't be overwriting existing ebuilds, and portage will only do
it if its in the PORTDIR - or do you mean when you manually bump? (If so, ignore
the entire comment block ending....<HERE>)
> 
> > 
> > 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.

In that case, ping cab - I believe he's working with Michelle's overlay of
Catalyst to get it into portage.
 
 
> 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.

I take requests for g-cpan :) Seriously, I feel like this email is degrading
rapidly, and will blame myself for being too defeneive the first time around.


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

When it was originally implemented, very. We were originally installing
everything to site, but were running into issues with core perl modules getting
sucked under and causing bad breakage. It's probably about time to re-examine
that patch (you're not the first to bring this up). Personally, at this point
I'd favor site_perl->vendor->core, so portage fills in above core, but what you
install manually overrides our ebuilds. Doesn't solve all of your problems, but
it would be a good step.

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

Thank you :)
> 
<snip huge nice section that was worth reading>
> 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?
> 

eh, unfortunately not. Until all of CPAN is under a better qa watch, we still
have to do manual qa and file rt bugs like everyone else (and I have a score or
two open right now). While some modules are 'trustworthy' for bumping, not all
are.
 
 again, sorry for the huge delay in responding,

 ~mcummings

-- 

-----o()o----------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net 
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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]