Niels Thykier <[email protected]> writes: > 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: Yup, that looks right. > 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. Yup, they should be identical formats. > 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. Yeah, files looks like it's not used. The goal was originally to accumulate all of the files that a *.dsc file refers to, but it looks like we're getting the size instead. My guess is that there's no point to that field. I don't think either architecture or standards-version are used. I suspect we could drop both of those unless we wanted to generate reports on the architecture and standards version used in the archive for some reason. (And we could always add them back in later.) > 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 think this is left over from an earlier refactoring. I think there may have been a maintainer field there at some point in the past. This can go now; it's just a complicated way of setting it to undef. > 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. The only other thing that occurs to me is that the current templating done for html_report is really not very good. I tried to keep the HTML page generation logic separate, but so much code had to go into the template that they're almost hard-to-read Perl modules at this point. I don't know if a different templating language like Template Toolkit might let more of the logic move into either the templating language or the actual page. > 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)? The way the config file is parsed is weird and annoying, and it would be nice to integrate that better with the way we're doing configuration in general for Lintian. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
