Refactoring unpack/list-${type}pkg and Read_pkglists
Hi
As you may have noticed I have started to parts of Lintian with the sole
purpose to clean up and documenting magical parts. I have been looking
at our packages list (those stored in $lab/info/) plus the related tools
and I hope you can help me with a bit with understanding what we have
and why we need all of it.
I have already connected these files to Lintian incremental runs. The
flow is not really obvious to me, but it appears to go something like:
harness calls unpack/list-* to re-generate the "lab package lists".
The list-* scripts print if a package is new, removed, changed or
unchanged. With this, the "lab packages lists" are now updated.
harness reads this output and generates a "-p packages-file" from this.
It also rm -fr the entries in the Lab that was "removed" according to
the list-* scripts.
harness renames the old log, opens it and copies all the entries from
the previous log that are "unchanged".
harness then runs lintian with the "-p packages-file" it generated
before, appending the output to the new log file.
Finally it passes this log file to html_reports command and when that
returns, the website has been updated as well (modulo some mv of the
html dirs).
Looking at the parser (and unpack/list-* scripts) I see that aside from
the header, the format of the binary and the udeb looks identical. Do
anyone see a reason /not/ to merge the parser/writers for these two formats?
If we merge them I can almost throw out list-udeb and one third of
Read_pkglists, so I am a bit biased here.
Secondly... Are there any use for the "architecture" and the "files"
(not to be confused with the "file") field in the source package?
Architecture does not appear to be referenced and the "files" field
appears to be corrupted in all existing files, so I doubt we use it.
Thirdly, html_reports appears to be referring to a "maintainer" field in
the binary/udeb files (if it cannot find the source). As far as I can
tell, this will always fail since the field not present. That being
said, I might have overlooked something.
I see there is a reporting entry in private/TODO; are/were there any
specific plans/ideas not written down in that TODO? Personally I think
this could go hand in hand with providing a mirror-sync possibility for
(a future) liblintian-perl.
Finally, did I miss something or are there any "magic" parts I should be
aware of, if I start messing with this (other than if I break it, I
break the website)?
~Niels
Reply to: