Comment 4 for bug 1081500

Actually, approach (2) would waste even more, as we would still run them unnecessarily through the "test reverse dependencies" stage.

Analysis of current dependencies to see how far our current "test reverse dependencies" logic would get us with the approach from (1):

eglibc has build deps on binutils, gcc-4.7, and linux-libc-dev → complete

binutils has a binary depends on glibc and a build depends on g++ → missing linux-libc-dev, which could become a (redundant) build dependency to be picked up by the reverse depends tests.

linux-source-3.7.0 has a binary depends on binutils → missing libc6-dev and gcc; I think eglibc/libc6-dev probably isn't that critical as it shouldn't break the kernel build directly, but we would need some build dependency on gcc-4.7 on the kernel.

gcc-4.7 build-deps on binutils and libc6-dev; it doesn't have any build or binary dependency on linux-libc-dev, so a new kernel upload currently wouldn't trigger a gcc rebuild test.