webapp-config conflicts with a new feature of portage: EMERGE_DEFAULT_OPTS I have added --ask to this variable, and so every emerge acts like "--ask" is passed to this. During certain steps, webapp-config calls emerge, and it seems to hang because emerge is waiting for input. Perhaps the IO could be handled in a way to display the emerge output and pass the input back to it? As a side note, typing "Yes" and hitting enter got to portage, so the action continued. It just took me a bit to figure out what was going on.
*** This bug has been marked as a duplicate of 124440 ***
I do not believe this is a duplicate bug. webapp-config is a seperate application from the eclass. Unless the application itself is not going to call emerge, then this issue will not be fixed by removing the emerge calls from the eclass.
Hm, webapp-config never directly calls emerge. It imports portage though. It does that in order to access portage.settings. I don't see how that could trigger --ask. The webapp.eclass on the other hand contains a direct "emerge" call that we still need to replace. The portage version I have currently installed (2.0.54) does not provide the EMERGE_DEFAULT_OPTS feature. So I guess I should upgrade to unstable for a test. Which version features this new variable? Can you give an example under which conditions webapp-config hangs? Does it hang while you install/clean/upgrade and does it provide any output before it stalls?
vericgar, please reply to comment #3, thanks.
