Apparently, though unproven, at 00:23 on Thursday 10 February 2011, Nils Holland did opine thusly:
> On 13:34 Mon 07 Feb , Neil Bothwick wrote: > > Don't install glibc-2.13 if you either use prelinking or run postfix. > > After testing it on my netbook, which uses neither, I installed it on my > > desktop and home server and broke both. > > Thanks a lot, I've read your mail just in time. Actually, glibc 2.13 > krept onto my first machine Monday night - I generally test new > versions of such "far reaching" stuff as glibc on a single machine > first before letting to onto all of my boxes. I didn't have any > problems with the new glibc, and tonight I would have updated a few > additional machines, one of which happens to run Postfix. I guess I'm > going to delay that a bit now. ;-) This raises an interesting point. glibc is a problematic package, it's tentacles run very deep in any GNU system, it has a less than stellar history in terms of breaking gentoo systems (mostly due to inadequate testing before releasing to ~arch) And it's very difficult to downgrade it due to that hidden barf check in the ebuild. I have yet to find a supported, documented way to back out of glibc screw-ups; my way is to keep binpkgs of @system and use those. Yes it's true that downgrading glibc is often a sure road to suicide, but the current method is also unworkable. Surely, surely, there's a better way? I'd even go so far as to support a portage feature-request: automatic binpkgs of a sub-set of @system that the user must opt-out of in make.conf: python, portage, glibc, gcc, maybe a few other highly critical packages. What say you all? -- alan dot mckinnon at gmail dot com
