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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1081500 Title: Add autopkgtest for mutual rebuild-testing amongst glibc, linux-libc- dev, gcc, and binutils To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1081500/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
