[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DRAFT: Bits from the Lintian maintainers



Russ Allbery <rra@debian.org> writes:
> * Provide a way to more clearly indicate Lintian's certainty, the severity
>   of the problem, and the source of the rule that Lintian is checking,
>   rather than always collapsing that information into a simple three-level
>   error/warning/info hierarchy.  This would allow users to, for example,
>   see only the tags where Lintian is certain there is a problem, or easily
>   ignore tags for aesthetic issues that aren't violations of technical
>   requirements.  This sort of additional granularity is a necessary
>   prerequisite for running Lintian on all uploaded packages and rejecting
>   on serious Lintian errors, something that's been oft-proposed.

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 

> * 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.

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.

Anyway, the mail looks fine, please go ahead and post it to dda.

Marc
-- 
BOFH #71:
The file system is full of it

Attachment: pgpD6GBZeDut4.pgp
Description: PGP signature


Reply to: