Re: Refactoring unpack/list-${type}pkg and Read_pkglists
Niels Thykier <niels@thykier.net> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: