app-portage/eix, when scanning overlays (ie, no portage metadata), attempts to execute ebuilds with /usr/libx32/portage/bin/ebuild.sh, but sys-apps/portage installs ebuild.sh to /usr/lib instead of /usr/libx32
I'm not sure which one is right, but they need to match for eix to work properly.
You'll have to figure out which gets it right and then blame it on the one that gets it wrong. Until then we have no bug.
(In reply to Jeroen Roovers from comment #1)
> You'll have to figure out which gets it right and then blame it on the one
> that gets it wrong. Until then we have no bug.
That's something the Portage and EIX authors need to decide.
You still haven't explained the actual problem.
The question is, does ebuild.sh belong at (on a x32 system):
If libx32, then portage is broken. if lib, then eix is broken.
Wherever portage decides to put ebuild.sh, it is right by definition:
Calling ebuild.sh is undocumented, and eix uses it only for the cache method ebuild*, because it is much quicker than calling ebuild - but obviously this is a hack in eix.
The path to ebuild.sh is determined by eix variable EIX_EBUILD_SH (and thus can be changed e.g. by setting this variable in the environment or in /etc/eixrc); its default value is determined in the eix ebuild by:
Do I understand correctly that $(get_libdir) should be changed to lib on all systems? Or is this only a x32 peculiarity?
x32 uses /usr/libx32 for all compiled libraries, similar to how amd64 uses /usr/lib64 for all compiled libraries.
# ls /usr/lib
debug gcc portage python-exec systemd tmpfiles.d
Obviously Python and Portage are not compiled, so I'm not sure what is expected.
exit needs to use /usr/lib/portage/bin/ebuild.sh regardless of the default ABI. that is how portage installs its files. that it works on current amd64 systems is an accident.
closing since eix-0.30.2 with the fix is in the tree
*** Bug 518942 has been marked as a duplicate of this bug. ***