On systems that run multiple slots of gcc for various reasons, the gcc ebuilds should not take it upon themselves to change the system default! This is wrong behavior. Unless there's a valid reason why the ebuilds need to set gcc-config default that offsets the various reasons why it should not... I recommend that this be removed. Perfect example: I just wasted several hours compiling stuff, totally unaware that a gcc-3.3 upgrade had switched my system back to gcc-3.3 when I specifically set it to 3.4. I want it to use 3.4 unless I change it back temporarily for some reason. Reproducible: Always Steps to Reproduce:
leaving the switching of slots to the user would be very appreciated, as unnoticed changes by portage can be indeed very wasteful and shouldnt be caused by portage
this has nothing to do with porting work, and everything to do with the toolchain. re-assigning...
afaik this is needed for proper operation when merging, but azarah might have more insight.
Well, I did not want to do anything there until when we actually get portage sorta there to start working on cross-compiling. The answer might be though to do the same as opengl-update - add a --use-old flag that do not set it if already set ... comments?
seems to happen now
