So you're aware, masking glibc 2.3 after it's been in the ~x86 keywords for a bit was probably a _very_ bad decision: anything compiled with glibc 2.3 will _not_ work with glibc 2.2, which will cause a lot of very broken systems. I know of one case where this has happened already; important things such as bash and python (for portage) were compiled with glibc 2.3 before an emerge -u world with ~x86 went back to glibc 2.2.5. Fixable generally - except that most people will have compiled gcc after merging glibc 2.3, which means they can't build anything to fix it. Overall, people ought to look before they merge, but it's still something worth considering. Recompiling static packages is a lot easier than trying to recover when something like gcc is broken.
My bad .. I told spider it was ok to mask after he though that its a bad idea. Anyhow, why I marked it as testing, was that we could sort out all problems, as the few minor issues with upgrade is better to get over with now *before* 1.4 is out ..
I've fragged my system after an emerge -u world, using 1.4_rc1 and unstable branch. Could a Gentoo developer please create a rescue .tbz file with all the needed GLIBC 2.3 files which then can be extracted over the damaged system by using the rescue cd, please? Also see http://forums.gentoo.org/viewtopic.php?t=19662
Would it be possible to change the glibc 2.2 ebuild so that it refuses to build if 2.3 is already installed? That way it would be harder for somebody to hose their system if they've already got 2.3.
Sounds like a pretty good idea to me. What about figuring out what breaks with glibc 2.3.1 and have the ebuild re-merge the packages that'll break? Whenever it's unmasked again, that is.
2.3.1-r1 is out now, it should fix all the stuff that is broke
