Re: DRAFT: Bits from the Lintian maintainers
Marc 'HE' Brockschmidt <he@ftwca.de> writes:
> FWIW, two years ago (?) Jeroen, djpig and I had a discussion about
> this. The basic idea back then was the same as you describe now: Move
> away from "E", "W" and "I" and use two letters to indicate the two
> different measurements are represented:
> (i) How certain lintian is: Some checks are heuristics, in other cases
> lintian is absolutely sure.
> (ii) How "bad" a problem is. A spelling mistake (kde instead of KDE) is
> a bug - on the other hand, broken shlibs handling might be harder
> to detect, but leads to actual problems.
>
> I don't have notes from that meeting (and I think there were never any
> notes published), so the rest of
That's pretty much the same, yup. I think we should probably provide a
mapping to E/W/I for backwards compatibility but provide a way of getting
more information. I think there's a third metric in addition to the two
that you list, namely "where does this rule come from," so that people can
selectively enable or disable classes of rule origins, although that's
probably less common.
>> * Better information retrieval, and caching, of lab information during
>> checks. Right now, all of Lintian's check scripts repeatedly open and
>> reopen files in the laboratory and reparse data in each check script.
>> Instead, that data could be loaded on demand and then cached in case
>> another check script needed it.
>
> ACK. Let's get rid of the lab idea, it doesn't help to make lintian
> easier. While we are at it, we could also finally document what data is
> collected by lintian in what format. I sometimes need to create a static
> lab, check a package and look at the unpack results to find out what is
> already collected.
I'm not sure about eliminating the lab entirely, since it's useful as a
resource for other sorts of checks and greps, but I think the first step
regardless is to provide an abstraction layer for reading data from the
lab that caches. Then, if we so choose, we could replace the data source
behind that abstraction with some other system without having to change
any code.
I should try to prototype something and implement a simple data method so
that everyone has an example to look at.
> Another idea discussed in that meeting two years ago was to extend
> lintian by adding a second tool using pbuilder/piuparts for some checks
> that require data from other packages. This would of course require net
> access (or at least access to a Debian mirror), but would finally allow
> to fix the twenty-something wontfix bugs that require access to other
> packages.
I'm not quite sure how that would fit into the other stuff that lintian
does, but definitely something to keep in mind.
> Anyway, the mail looks fine, please go ahead and post it to dda.
I'm just waiting for the complete archive run to finish so that the
uploaders information is there, and then I'll do that.
Thanks for the review!
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: