Running "g-cpan -u" on either of my machines now results in what seems to be an infinite loop. I haven't left it running all night or anything, but I do get the following lines repeating for as long as I've let it run: * g-cpan: Looking for Bundle::CPAN Is already unwrapped into directory /root/.cpan/build/Bundle-CPAN-1.854 WARNING: SIGN is not a known parameter. * g-cpan: Ebuild already exists for Module-Signature * g-cpan: Ebuild already exists for Scalar-List-Utils * g-cpan: Ebuild already exists for YAML * g-cpan: Ebuild already exists for Compress-Zlib * g-cpan: Ebuild already exists for Archive-Zip * g-cpan: Ebuild already exists for File-Spec * g-cpan: Ebuild already exists for File-Which * g-cpan: Ebuild already exists for Expect * g-cpan: Ebuild already exists for libnet * g-cpan: Ebuild already exists for Term-ReadLine-Perl * g-cpan: Ebuild already exists for Digest-SHA * g-cpan: Ebuild already exists for Text-Glob * g-cpan: Ebuild already exists for Archive-Tar * g-cpan: Ebuild already exists for Module-Build * g-cpan: Ebuild already exists for TermReadKey * g-cpan: Ebuild already exists for ExtUtils-CBuilder * g-cpan: Ebuild already exists for Test-Harness * g-cpan: Ebuild already exists for libnet * g-cpan: Ebuild already exists for File-HomeDir * g-cpan: Ebuild already exists for Data-Dumper * g-cpan: Ebuild already exists for CPAN-Reporter * g-cpan: Ebuild already exists for YAML-Syck What would I have to do to keep my current CPAN config options, but purge any and all caches CPAN or g-cpan might have? Just a hunch... But even if that fixes it, it's still a bug. Once again, g-cpan is useless. Running the latest stable g-cpan and portage, on amd64, as of about an hour ago. I'll attach "emerge --info" from one or both machines if needed, Bugzilla won't let me paste them here (comment too long).
(In reply to comment #0) > What would I have to do to keep my current CPAN config options, but purge any > and all caches CPAN or g-cpan might have? Just a hunch... There's no cache to purge. It's based on whatever the latest downloaded 02/03* file is from cpan (the list of modules and packages), and whatever is sitting in your overlay. > But even if that fixes it, it's still a bug. Once again, g-cpan is useless. Constructive comment. > Running the latest stable g-cpan and portage, on amd64, as of about an hour > ago. I'll attach "emerge --info" from one or both machines if needed, Bugzilla > won't let me paste them here (comment too long). Would you be willing to tar/gzip up your perl-gcpan overlay so I can see if -u loops here as well? Then again, I suppose that might be useless to.
(In reply to comment #1) > (In reply to comment #0) > > But even if that fixes it, it's still a bug. Once again, g-cpan is useless. > > Constructive comment. Sorry, that sounded worse than I meant it. I mean, this is the second g-cpan bug that's left me completely unable to use it for what it's intended. Attaching my perl-gcpan overlay...
Created attachment 102811 [details] perl-gcpan overlay I can reproduce this bug on another machine, let me know if you want that overlay as well.
just sticking my head in to say i'll work on this this week, don't want you thinking this is lost/forgotten. I'm aiming to put an rc into portage once this bug is resolved (and for the other bugs resolved lately) :)
Fixed in svn (or it will be in a few minutes). Finally tracked this down (thanks for the copy of your repo!) The "bug" was that we "analyze" the .pm files in the bundle to see what they list in a somewhat sloppy fashion (could be better, but it works for now at least). In the case of Bundle::CPAN there is a reference to Bundle::CPAN later in the .pm, so g-cpan blithely marked it as a dep and pursued it over and over and over again. Fixed in CPAN.pm (next if dep and module are the same name). I'll push this into the tree later this week (~arch'd) for more testing. Thanks for your patience!
Hmm, sounds good, but if I understand this, we'd still have a problem with mutually recursive dependencies. (This solves the GNU's Not Unix problem, but not the HURD/HIRD problem.) So, what do we do if package A depends on B which depends on A? Can we build a hash (Perl terminology -- an index, say) of everything seen so far, such that at the end of it, we use that as the list of packages to feed directly to Portage (and we never process the same one twice in the same run)? I'm tempted to jump in and see how this all works. Oh, and thanks for the fix, even if I don't have it yet.
I'm going to go ahead and mark this fixed since the original problem has been corrected :) As for your last question, ironically we fixed the horse before fixing the cart (does that analogy work here?). We already track the deps and remove them from the queue if we've already seen them - the problem in this case was that we do it after we've finished processing an item, and the reference was internal to the bundle::cpan processing. A to B to A should never happen.
