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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
