On Wed, 8 Jan 2014, Peter Stuge wrote:
lin pro wrote:
This time it is about help2man requiring Locale_gettext pearl
module package.
The message in itself is very simple and clear. There is no
dev-utils/Locale_gettex available for emerge durring the configure
phase.
At first that might seem like a bug in the help2man ebuild.
However,
RDEPEND="dev-lang/perl
elibc_glibc? ( nls? (
dev-perl/Locale-gettext
) )"
..the dependency looks fine, meaning that dev-perl/Locale-gettext
is in fact installed on your system.
The problem may be that perl has been upgraded, perhaps as a result
of using a newer portage tree for the stage4 than the stage3 was
built with, but perl modules haven't been upgraded to be availble in
the new version of perl.
My first impression is the same. You likely need to update / redo your
stage3 so that your perl applications are built for the same perl version
that stage4 is picking up.
Either chroot into the stage4 temp dir as already described, or hack
the catalyst stage4-chroot.sh script to run perl-cleaner --all right
after run_merge -uav system.
My question is hwo to tacke those problems from within catalyst.
Avoid the problem by building a full set of stage1, stage2, stage3
and stage4 using only one specific portage tree.
From my experience building and debugging catalyst builds, the hardest
part is getting a working spec. When you have a spec that builds, you just
need to check packages that fail to build to see if they have become
broken or check here (or even better #gentoo-releng) to see if there were
any changes to the tree that break catalyst or stage building.
//Peter
Regards,
Jorge Manuel B. S. Vicetto
