From time to time I have to use very pretty portage's feature (generating rpm packages, now on amd64 system). On last iteration I've met one miss. For example dev-php/tcpdf: ebuild /usr/portage/gentoo/dev-php/tcpdf/tcpdf-5.9.149.ebuild rpm … Wrote: /var/tmp/portage/dev-php/tcpdf-5.9.149/temp/rpmbuild/RPMS/x86_64/tcpdf-5.9.149-r0.x86_64.rpm … Portage detects x86_64 arch from my system. But this package uses compilled (for proper arch) php interpreter and it's code don't depends on target system arch. Native package (quote below is taken from rpm-based distr): # yum search tcpdf … php-tcpdf.noarch : PHP class for generating PDF documents is classified as 'noarch', not 'x86_64'. It would be fine, if portage's ebuild command will set proper arch (i.e. 'noarch') on building interpretable or documentation packages. P.S. Division applications into two classes (arch-depended (compilable) and arch-independent (interpretable or documentation)) could be useful and in Gentoo itself: for example on gcc-update I can find it pretty to rebuild all compilled applications, but I'm not pleased with add-on of necessity to rebuild all other interpretable and documentation packages.