Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 488320 - =sys-apps/portage-2.2.1 ebuild rpm incorrectly detect 'arch' for interprete program languages packages
Summary: =sys-apps/portage-2.2.1 ebuild rpm incorrectly detect 'arch' for interprete p...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Portage team
Depends on:
Reported: 2013-10-17 07:00 UTC by Sergey S. Starikoff
Modified: 2022-10-20 02:44 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sergey S. Starikoff 2013-10-17 07:00:18 UTC
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.