Re: [gentoo-catalyst] I need generic solution to package non-building uder catalyst...

["Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>]

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