Hi,
thinking about this again, there are currently two tasks performed by
detect_well_known_errors:
1. generating .kpr files
2. generating .tpl files
(1) is the really time comsuming part and needs to be run independently
from piuparts-report from time to time (with the recheck options ...),
so it needs to stay in a separate script.
On the other hand, I think (2) should better be integrated with
piuparts-report - making the intermediate .tpl file superfluous while
reusing the packagedb with dependency counts that is already there.
A known problem specification is currently something like
* a set of patterns (grep foo | grep bar | grep -v baz | grep -v blah)
(processing them with re instead of repeated grep calls sounds like a
good longterm goal)
* header, description (in .conf), title (in piuparts-report)
* ordering information (in piuparts-report)
* an indication where to look (error or issue) (repeated three times:
*_{error,issue}.conf, WHERE, ISSUE)
Then we repeat most of them a second time with slightly changed
header/title and error/issue exchanged ...
There is a little special case: the unknown failures.
What I'd like to see is (in probable order of implementation)
* piuparts-report "discovering" all existing known problem descriptions
instead of hardcoding them
- need to add ordering information somehow, perhaps by adding a
number prefix: 42_foo_not_found_issue.conf
or by adding a variable with a sort key inside
(there should be a bug or some todo entries about this)
- needs to move title information from piuparts-report to .conf
* piuparts-report generating the known problem reports, allowing access
to packagedb etc. for "better" reports, making .tpl files obsolete
* getting rid of error/issue redundancies
* computing the .kpr with python re instead of grep
* adjusting the .conf and .kpr formats to what is actually needed
For performance reasons directory content should be cached heavily (e.g.
use listdir() exactly once, avoid exists() etc., maybe LogDB can be
reused). Be aware that files (especially logfiles) may disappear at any
point in time - catch and ignore.
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
