Failed dependency counts differ from pbulk output

[bsiegert]

@jperkin noted that https://releng.netbsd.org/bulktracker/build/1042 has very different stats from the pbulk report at https://us-central.manta.mnx.io/pkgsrc/public/reports/upstream-trunk/20240713.1508/meta/report.html.

They are the same results, but the algorithm to find "packages broken by this one" etc. are different from what pbulk uses.

For example, in the pbulk report, archivers/ark lists failed deps as

Failed: libunwind-18.1.8 py311-gi-docgen-2024.1

In https://releng.netbsd.org/bulktracker/pkg/27867777, the failed dependencies listed are all indirect-failed as well.

ark does not depend on py311-gi-docgen directly. Instead, it depends on qt5-qtbase, which depends on libproxy, which depends on py311-gi-docgen. You can find this by clicking through the links under "this package has x failed dependencies".

bulktracker could do the same thing that pbulk does, i.e. consider all dependencies (direct and indirect) and keep only those which failed. Would that make more sense than the current behavior? Not sure.

[gdt]

What I care about is finding the packages that actually fail (meaning their deps package, but they fail). I don't consider "indirect-fail" to be useful. What i want to know is that for each actual failure, some measure of how much trouble it causes. I think that's the total number of packages that depend (directly or indirectly) on the failing package. Yes, that could overcount in that if A and B both fail, then everything that depends on A and B will be counted twice, and the sum of "packages broken by X" over all X will be more than the number that failed to build. I think that's ok. I'd also be ok with allocating fractional responsibility, but I think it's unhelpful, error pone, and a lot of work.

[gdt]

I should clarify: indirect-failed should perhaps be labeled "dependency-failed" to make it clearer, and it's a fine status if I ask "tell me about foo/bar". But it doesn't belong on a "list of failing packages".