Otherwise some important patches may not be applied.
*** Bug 49528 has been marked as a duplicate of this bug. ***
Only time this pops up is ebuild phase; I'd be more inclined to say, what you had for USE settings during setup phase, is what you end up with. If that suffices, this bug is addressed by 56408
I'm not 100% sure what you wanted to say Brian. Since I never had the time to look at portage sources - and I don't really like to, until it's a bit more stable - I don't know the difference between ebuild and setup phase. Is the latter after all variables are determined? My problem (Bug 49528) is the following: Having keepwork in FEATURES and testing different use flag combinations is not possible, since always the first use flag set is used. Needed a while to find that out, once. And always rm -rf "workdir" is annoying. I don't think bug 56408 is addressing this issue.
Another one: When a user does ctrl+c after the unpack phase, because he forgot to set a use flag, no clean up happens and the old environment gets reused until the user removes the temporary data by hand or touches the ebuild. I have seen such bug reports a few times and it is really confusing, if you don't know what happens. Imho the environment should always be redone and not cached.
*** Bug 60095 has been marked as a duplicate of this bug. ***
If portage does not clean the workdir, what does the feature keepwork do then?
>If portage does not clean the workdir, what does the feature keepwork do then? I don't know what the original idea was, but I use it to be able to do `emerge <foo>` instead `ebuild <foo> <command>` for ebuild testing/bug squashing. I'm too lazy to type more than necessary.
*** Bug 68186 has been marked as a duplicate of this bug. ***
unless you are doing something like emerge --resume, workdir should be cleaned
(In reply to comment #9) > unless you are doing something like > emerge --resume, workdir should be cleaned The environment is kept in $T. And I still can reproduce this annoying behaviour with the stable portage. Apart from that, there has just been another related bug report regarding the workdir opened. >> Bug 100095
*** Bug 102290 has been marked as a duplicate of this bug. ***
Carsten, dump portageq envvar FEATURES
became a victim of this annoying behaviour too... # portageq envvar FEATURES autoconfig buildpkg cvs debug distlocks keeptemp keepwork multilib-strict noauto nostrip sandbox sfperms test
Can someone provide an actual testcase for this including the resulting problem (instead of just the cause)? I have some problems understanding the core of this bug and what the solution should really be.
