tetex.eclass generates a Gentoo-specific tetex-update shell script which in turn invokes texconfig to perform certain tasks. tetex-update runs texconfig using &>/dev/null. This effectively causes the install process to hang indefinitely if texconfig should encounter an error, because texconfig uses dialog to report errors - and due to the redirection the user never even gets to see the error dialog, much less dismiss it. This happened on the system I'm installing right now when merging the latest teTeX beta - note that it was a fresh install, no previous teTeX installation was found, and texconfig complained (to be expected in this case). The issue can be worked around by simply killing the tetex-update process or by repeatedly killing texconfig or dialog until the script finishes invoking them, but that's not very clean. This issue is very inconvenient for unattended installations. The good intention of the /dev/null redirection is completely lost in this case and in fact backfires. I'm not sure how one should handle a problem like this - patching texconfig would be an option but it would cause problems *after* deployment since then the user would probably want to see texconfig's errors.
Thanks for the bug report. It should be solved before tetex-3 inclusion. Portage should not ask users to run interactive configuration (dialog interface in this case) during emerge, so I suppose we need to patch texconfig (but tetex-2 doesn't have this problem, do it?)
I think tetex-2 also exhibits this behavior - looking through the eclass file didn't show anything specific to the beta-3 line. I'm reverting to 2 now (the beta-3 line didn't generate some seemingly required files and I'm not familiar enough with teTeX to figure out how to fix it, just need it to run doxygen). For now I've deleted /var/lib/texmf and /usr/share/texmf which should trigger the very same behavior again if it is the case. I'll get back to you after it's merged and after I've investigated exactly what happens in tetex-update when no previous teTeX installation existed (perhaps it could be skipped entirely if that should be the case).
OK, tetex-2 isn't affected, merge went ahead just fine.
This isn't a problem anymore with tetex-3.0. Please reopen if the problem still persists.