When upgrading binutils and the toolchain-binutils_pkg_postrm() function detects a change in target, it calls binutils-config -u on the old target. The uninstall_target() function in binutils-config does not see the newly upgraded TARGET and HOST and refuses to "uninstall the native binutils". The emerge then continues to remove the old binutils version, leaving the old binutils env.d files, libs, and bins. Subsequent usage of binutils-config reports the old version still exists, calls to remove it fail, leaving binutils in an inconsistent state. Reproducible: Always Steps to Reproduce: 1. Extract stage1-x86-2005.1-r1.tar.bz2 2. Extract most recent portage into stage1 location. 3. Change CHOST in make.conf 4. emerge binutils Actual Results: emerge -s binutils shows only most recent version installed binutils-config -l shows both versions still install binutils -u i386-pc-linux-gnu-2.15.92.0.2 fails Expected Results: The toolchain-binutils.eclass should either update its environment correctly before calling binutils-config, or binutils-config should not attempt to bypass the removal of a profile under any circumstances. The eclass should take precedence. Have no idea if this bug happens on other archs, stages, or changes in version only.
this is only an issue when changing your native CHOST fixed in cvs
Don't know if this matters or not, but the x86 stage3 tarballs still have the remnants of the old binutils in /usr/i386-pc-linux-gnu and /etc/env.d/binutils/config-i386-pc-linux-gnu still exists. They don't appear to bleed over into the environment or anything though.
