This is *not* the same as bug 12689, but is related. I emerged gcc-config (and some other stuff) (already had colorgcc installed). From that point on, all other ebuilds failed during ./configure (they were trying to run /usr/bin/gcc, which doesn't exist). After a bit of digging I realised that it was because of the wrapper versions from colorgcc, and once I had done an update emerge on colorgcc to get the latest version, everything was fine. colorgcc should be forced to update to the new version if the new gcc-config is installed - the emerge system is left almost unusable if you don't. phil
Fine by me, but no way for me to do with current portage features. Adding Nick ...
The latest perl ebuilds give me an idea about this. All the gcc ebuild would need is something like: if $(has_version dev-util/colorgcc) ; then PDEPEND="${PDEPEND} dev-util/colorgcc" fi However, there are a number of bugs that prevent this from working. First, PDEPEND is not working as advertised, the way I understand the advertising. I thought PDEPEND is supposed to emerge the packages in PDEPEND unconditionally after the current package is merged. What I'm seeing instead is the PDEPENDs only being merged if the package is not already installed. I'll post a patch to fix that. Second, the dep cache in /var/cache/edb/... is only updated when the ebuild is newer than the cache file, AFAICT. The problem is that when the cache is created, it doesn't take into consideration the conditional PDEPEND, but saves away the current value of PDEPEND at that time. So, in this case, if gcc is merged without colorgcc installed, the cached deps will not list colorgcc. Then, if the user emerges colorgcc, and then later merges gcc again, the dep cache will still not list colorgcc. All I can think to fix this problem is to add a flag to the ebuild that says to not use the cache. At any rate, it would be cool if this worked.
Created attachment 7367 [details, diff] emerge.diff Force PDEPENDs to be merged unconditionally.
Hmm, simple patch. Well, the problem is also fixed by gcc-config-1.3.1.
This bug has been inactive for more than 180 days. I believe the problem's been fixed. Please reopen if it persists.
