Okay let's see a moment what's going on with the slotted boost. www-plugins/gnash has a blocker on the old unslotted boost because it doesn't really support multiple boost that well, like most other packages.
sci-biology/cufflinks and sci-biology/express are next to completely screwed because they are hardcoding boost-1.46 (which is soon going to make them unusable). Besides, cufflinks shows that it's the kind of crap that should never have entered the tree, considering that filter-ldflags on --as-needed which is not going to do its job even if you pray. dev-util/intel-ocl-sdk does the same, but it might just install its own version since it's not going to work anyway. There was an ebuild for net-analyzer/sslsniff but I removed it since there was a -r1 that works just fine with 1.47 and later. I'm going to give it time till tomorrow to hear if somebody has a good reason to have the slotting (which has to be a _valid_ reason, not a fantasy reason like the ones I heard today about being able to install 1.35 on a modern system). If nobody else can demonstrate a need and a way to leverage the slotting, I'll go with just go this way: - maintainership moved to me+scarabeus+cpp herd (which means Tiziano is still there, btw); - blocker on gnash removed; - intel-ocl-sdk, cufflinks and express will request a particular version (which makes them trouble, but it's mesesd up all the same — optionally I could just go and mask them until properly fixed); - old ebuilds removed from tree with their files, to reduce the rsync trouble. Hopefully then it'll work just as before, with the latest version available unversioned so that old packages relying on eselect will work out of the box, which is what should happen anyway. I'll also run a tinderbox against 1.51, and will start to look into what has to be done to fix whatever is still incompatible with it to work, so that when glibc 2.16 gets out we can unmask this without breaking the 70% of the tree like an unmask of >=1.50-r2 would cause right now. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
