[Piuparts-devel] faster-rdep-calc/rdep-chain-len

[Dave Steele]

On Sat, Apr 13, 2013 at 1:32 PM, Andreas Beckmann <anbe at debian.org> wrote:
> Hi Dave,
>
> looking at the branches again, there are a few commits that should be
> separated from the branch and merged first:
>
> * "Remove need for chdir() before loading packagesdb."
> (there is an unrelated change to calling calc_rrdep_counts(), that
> should be moved to "Use the on-demand versions of the rdep metric calls.")
>

Ok... but we are venturing into bike-shedding territory.

> * "piuparts-report.py - Avoid sorting passed files by block count." and
> "piuparts-report.py - Refactor with_count in write_state_pages()."
> should be merged and "reverted" to use the old rrdep interface
> temporarily. This is a "bugfix", although the bug is not noticable with
> the old interface.
>

That is not a bug in the context of the old rdep sort behavior. Block
counts for passed logs are zero - no special consideration is needed
for the sort. It only makes sense with the new behavior, as a
performance optimization.

> Furthermore I ran into problems with dwke on logs that have no longer
> existing packages (see trace below) ... I shuffled around the patches a
> bit and changed the rrdep accessors to a) take a package name instead of
> a package and b) return -1 if the requested package does not exist.
> You can find the first part of that work in
> preview/fast-rdep-interface:
>

By testing for None in the accessor and returning -1, there becomes a
need for special handling in both the caller and accessor. It is
already the responsibility of the caller to pass a valid object. In
detect_well_known_errors, this is result of the bullet proofing you
asked for earlier. The fail you list here is in a try block to catch
just this - it just no longer looks for the right exception after a
recent rebase. I've added AttributeError to the catches.

I'm no longer sure whether or not piuparts-report needs to guard
against this. It didn't, before resolve_virtual. PackagesDB should
guarantee that the package lists are consistent.

The preferred package type argument for the rdep metric calls is
pretty evenly divided. I'm leaving it a the package object for now, as
the more efficient form.

With that, I think I've addressed the open issues related to
faster-rdep-calc and rdep-chain-len (BTW, chain-len is now useful -
resolve-virtual was the fix to cause the waiting-for-dependency count
to be driven quickly to zero). Some rework remains after the chdir()
elimination goes to the front of the line, followed by testing. There
are still a few issues remaining with the original
detect_well_known_errors submission that I expect to address.