Bugzilla Bug 101088

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 an attachment (id=64930) [details]
Change the DEPEND to !uclibc_elibc? ( !features_noman ( ..

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