> The ebuild and package are quite difficult (like all sci packages). A
> homebrew'd configure script and no way to change the path for config files.
> Not sure what needs to be done really. Probably best to see the first
> version that worked and what changed. At some point, everything that was
> added to the prefix tree was tested. New versions after were not explicitly
> tested when they were added to the tree. We rely on bug reports and people
> helping to fix issues. :)
> 

Fair enough. Here my go in trying to at least localise the problem (Keep in
mind that I have no general knowledge of gentoo, other than running
gentoo-prefix.)

I notice that the lines 

eselect blas add $(get_libdir) "${FILESDIR}"/eselect.blas.atlas ${ESELECT_PROF} 
eselect cblas add $(get_libdir) "${FILESDIR}"/eselect.cblas.atlas ${ESELECT_PROF}

in blas-atlas-3.9.3.ebuild are apparently responsible for the problem.
Expanding the variables the first one translates to 
eselect blas add lib $EPREFIX/usr/portage/sci-libs/blas-atlas/files/eselect.blas.atlas atlas

now the interesting thing is that when I execute this line from the
commandline, then indeed it does the right thing, and basically copies
$EPREFIX/usr/portage/sci-libs/blas-atlas/files/eselect.blas.atlas
to 
$EPREFIX/etc/env.d/blas/lib/atlas

(The file eselect.blas.atlas does itself not look very prefix friendly, but
this is a different issue.)

however when this line is executed during "emerge blas-atlas", then there
seems to be some mechanism, which installs all files first to a temporary
tree under $EPREFIX/var/tmp/portage/sci-libs/blas-atlas-3.9.3/image/
Here is obviosly, where the error occurs, since the above eselect writes
into $EPREFIX/var/tmp/portage/sci-libs/blas-atlas-3.9.3/image/etc/
instead of
$EPREFIX/var/tmp/portage/sci-libs/blas-atlas-3.9.3/image/$EPREFIX/etc/

then the function install_qa_check_prefix() which is located in 
$EPREFIX/usr/lib/portage/bin/misc-functions.sh
notices that there are files to be installed outside $EPREFIX and barfs out. 

So far so good. What I do however not know, is why "eselect" misbehaves when
called from within emerge. 

I have now filed a bug for this, it is at
https://bugs.gentoo.org/show_bug.cgi?id=294606

So from my limited understanding this could well be a bug which is not
directly due to the ebuild (which seem to be a couple of months old), but
possibly due to eselect not doing the right thing when called from within
emerge. Was there any recent change in the eselect infrastructure that could
have triggered this? 

Andreas