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

Re: Lintian as a static analysis framework



Paul Wise <pabs@debian.org> writes:
> On Fri, Jul 8, 2011 at 12:30 PM, Niels Thykier wrote:

>> We could do it like that, though the vendor profiles specification
>> actually deliberately did not answer the question of how to add
>> third-party checks.  I know some people already do this, so we have made
>> Lintian behave sanely to it.
>>  The official "API" for adding third-party checks (and collections) is
>> on my TODO list (this incl. #359059 for those interested).

> I don't think running external checkers should be third-party checks,
> they should be integrated into lintian like all the other checks. The
> only thing that is different for them would be the decision about when
> to run them, which is IMO the role for profiles.

I really disagree.  I think that mingles two things together in a way that
won't be helpful.

The purpose of the profiles is to control which tags you want to see
because your upload target is different (Ubuntu versus Debian versus
Emdebian versus a local site with Debian packaging standards of their
own).  Checks with dependencies on other software that we don't want the
main Lintian package to depend on are basically orthogonal to that.  You
always want to run the OCaml checks if you can; you may not be able to if
you don't have the software available, but it's not something that varies
from Ubuntu to Debian, etc.

If we make those sorts of checks part of a profile, then everyone has to
keep updating their profile to account for new checks and we end up with a
combinatorical explosion of profiles to account for people who want OCaml
but not Java, for Ubuntu.  That's just extra maintenance burden to no good
effect.  And, more notably, the additional checks may themselves want to
use profile information to selectively disable checks on Ubuntu, etc.
Using profiles also doesn't solve the dependency problem.

The design strategy for checks with external dependencies is to have them
be provided as separate packages, which can optionally be installed and
which will automatically enable their checks if they're installed.  I
think that gives us the best overall flexibility.

These extra packages may all be maintained by the Lintian team if that's
the way that we want to go, or be maintained by the people who are expert
in that particular packaging area, or some combination of the two.  I
don't really want us to go hog-wild with lots of additional Lintian add-on
packages, since that could make things a bit confusing.  We may even want
to build everything from the Lintian source package, and just break things
out into separate binary packages according to the dependency impact.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: