[Piuparts-devel] What are we optimizing for? (cf. dwke + -report)

[Andreas Beckmann]

Hi,

what are our goals for overhauling detect_well_known_errors and
piuparts-report?

Dave aims at speeding up detect_well_known_errors. After having looked
at the timings, I must say, I don't really care about this point right
now. Generating .kpr from .log "just works" for me at the moment.

I have usability problems (from a developer POV) with the known_problem
report generation. Being scattered at the wrong places makes this hard
to extend: .tpl generation in a shell script, problem list and ordering
information hardcoded in piuparts report.
Currently this is not easy to extend. Speed is only secondary.

Somehow I'd like to get "non-blocking failures" implemented. More about
this was in a lenthy mail some weeks ago.

And we should probably group the failures "by phase" as the same error
type can happen in different phases, and some may be more interesting
and some just boring. Lets take as example a lenny->squeeze->wheezy test:

* install depends
* install package/lenny
* distupgrade squeeze
* install package/squeeze
* distupgrade wheezy
* install package/wheezy
* check installed package
* remove
* checks after removal
* purge
* checks after purge

(install package/foo whould just be skipped if package/foo does not
exist - just think about squeeze2backports2wheezy tests of a package
with versions (None, 1~bpo, 2) in the three distros.)

Any failure (e.g. postinst fails - that could happen at several places)
before "distupgrade squeeze" would be rather boring for this test, as it
will be the same failure as in lenny or lenny2squeeze and nothing we
need to care about in l2s2w. But we can't just inherit all failures from
lenny2squeeze: failing to remove/purge in l2s is nothing that can happen
in l2s2w.


Andreas