Re: Refactoring unpack/list-${type}pkg and Read_pkglists
Niels Thykier <niels@thykier.net> writes:
> My first problem is adding/replacing a package in the lab, because the
> package lists (in some cases) appear to contain more information than
> the available in the package meta data. This means adding a source
> package via the dsc file (e.g. lintian --unpack $dsc) does not produce
> the same result as using unpack/list-srcpkg.
> The full list of fields we need are in [1], but the problematic one
> appear to be "area" for source files. For bin files we could extract
> the deb control file and (ab)use the $section field, but I cannot seem
> to find something useful for the source package[2].
Yeah, the area isn't in the *.dsc file. You have to unpack the source
package and look in debian/control to get it.
> I am tending towards just blanking the field in this case and let
> html_reports do a src->bin check for the area.
That seems reasonable to me.
> There is also a second problem; namely making a package list file for
> changes-files (if only for symmetry). Though I think source, version,
> file and timestamp should be enough for that.
Yeah, that also seems reasonable.
> If this plan work out, harness would be updated to use the lab to create
> the mirror diff. With the diff, it would then hack the log (as it does
> now) and then have lintian do it regular run.
> On a related note, I am thinking of making lintian accept a
> --from-file (or similar) argument that makes lintian read files (or
> package names) from a file (or stdin). Looking at the code, the
> --packages-file seems like overkill (we discard all but the file field).
Your plan sounds great. :)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: