"Arttu V." <[email protected]> writes: > It looks like the @INC list (the directory list perl uses for finding > its modules) is not right or is not processed right. Only one > directory is looked into? (You can see @INC with "perl -V", it should > be up to about ten directories on a Gentoo install.)
Doesn't seem to have been related to @INC as that variable contains all the usual suspects. Far as processing that may be the problem. > Unless you really, really want to know exactly which bit from which > package is sideways you might get out of the hole simply with: > perl-cleaner --reallyall Thanks for that. I did `perl-cleaner --reallyall' but the emerge process engendered by it failed again at the same perl module: perl-core/Module-Build-0.400.0 ------- --------- ---=--- --------- -------- Here is what seems to have fixed things up... I'm not sure if all of it is required, but what I finally did was unmask the hard mask on perl-5.14 Emerged that with -uD flags which caused the same troublesome perl-core/Module-Build-0.400.0 to be installed after the new perl was installed and it went by without a whimper. Then followed with perl-cleaner --all, followed by revdep-rebuild. (neither of those seemed to find much to do). Apparently the perl change was fully cleaned up during install so perl-cleaner had nothing to do. And finally `eix-sync' followed by `emerge -vuDp @world' which revealed that those troublesome perl modules: perl-core/Module-Build-0.400.0 and Parse::CPAN::Meta are now not coming up since they are installed. However I see a new gcc in the output so thinking I'll install that by itself and set the new one up as active before doing `emerge -vuD @world' I'll post this once I see if a full emerge -vuD @world works without failure. tic toc . tic toc .... OK, the full `emerge -vuD @world', followed by `revdep-rebuild' has gone down trouble free.... all fixed I guess.
