[gentoo-user] Re: perl versioning problem, how to get beyond for @world

[Harry Putnam]

"Arttu V." <arttuv69@×××××.com> 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.