Unpacked a fresh uclibc-hardened stage1 for bootstraping purposes. Changed my ACCEPT_KEYWORDS to ~x86 and begun the bootstrapping. After that the 'emerge -e system' seems to b0rk, just because ~groff (1.19.1-r2) fails (see bug #98187 for reference). After changing the libperl ebuild (so it only checks noman if ublibc_elibc is unset), the emerge -e works fine.
Created attachment 64930 [details] libperl-5.8.7.diff
The infamous groff is back... Same problem in dev-lang/perl The problem needs to be fixed in stable : - sys-devel/libperl-5.8.6-r1 - dev-lang/perl-5.8.6-r5 Reassigning to embedded
Anyone talk to spanky about this? I think this was his addition to the libperl ebuild. And what about the perl ebuild itself?
SpanKY is on the embedded list
rather than dance around this all the frickin time, why does libperl need groff ? libperl will build and install just fine w/out it (after all, libperl is just the perl library, it doesnt install any manpages with it)
also, i just tested perl-5.8.7, and the only difference is that if you have groff installed, you get the blib/man3/Unicode::Normalize.3pm manpage ...
Historyically (I want to say at drobbins' insistance, but that could be foggy memory talking) the libperl and perl ebuilds were kept as identical - build style was determined by the PN, otherwise there was no difference in the two. Whatever. The libperl ebuild only builds the so file - needs the same patches, but so long as the dep doesn't affect the outcome (and in this case, groff obviously doesn't) there's no problem in dropping the dep and the headaches all together
As a workaround, the perl and libperl ebuilds are now back to "!uclibc_elibc? ( groff )" which should prevent them from breaking.
beu has been so kind as to punt groff completely