Re: lintian for Emdebian

[Russ Allbery <rra@debian.org>]

Hi Neil,

I'm really sorry that it took me nine months to respond to this message.
It had been sitting around waiting for me to find some time to think about
the issues that you raise with adding overrides with Lintian custom checks
and trying to figure out how to approach this problem.

Neil Williams <codehelp@debian.org> writes:

> No, the problem appears to be only when running the checks due to the
> arbitrary way that perl indexes hashes:

> # perform checks
> for my $check (keys %checks) {
>     my $ci = $check_info{$check};

> Sorting those keys puts manpages behind emdebian but then puts copyright
> ahead of emdebian which means that the copyright overrides are missed
> instead. :-(

> I can hack around it by then making the emdebian checks to be 00emdebian
> etc. but that is ugly.

I think I'm going to toss a sort in there for future versions of Lintian
just to make the results predictable (it's always much easier to test when
things happen in predictable sequences), but I agree that relying on the
order in which checks are loaded and using file names to force that is
ugly.  I think that's a sign that we'd be going down the wrong path.

> Even that needs some flexibility because I currently use
> Tags::add_override to selectively override tags dependent on the type of
> package so that I don't get too many unused overrides.

Hm, yes, that's a fundamental problem with using overrides for this.
Lintian wants people to clean up overrides.  What you really want is
something akin to an override, but which isn't treated the same way, isn't
processed as part of the package, and isn't expected to be active in any
particular case.

> What the code does not achieve is only loading this global override file
> upon request of the check script or under defined circumstances.

> I don't want to remove these warnings from lintian when, e.g. sponsoring
> packages for Debian - only when building packages for Emdebian.

> To do that, I'd need this code to be wrapped in a command-line option
> because whenever the check script is loaded it will be too late to
> prevent the existing checks from being removed.

This is a really good point.  I hadn't thought about this.

> It would be a lot cleaner if I could disable other checks within the
> check script itself by making Tags::add_override reliable and
> predictable. I wouldn't need a global override directory if there was a
> hook in lintian to set overrides *before* any other &run() subroutines
> are actually run (including my own). i.e. a second function in the check
> script Package::foo that lintian calls when the package has been
> unpacked but before any &run() functions are called.

The ongoing concern that I have about this approach is that it feels
unclean to me to have particular Lintian check modules be able to modify
the results of other check modules.  It feels like a layering violation,
and like the check concept is being a bit "abused" in order to introduce
code that isn't really related to that specific set of checks.

For the next version of Lintian, I've just implemented something a bit
different that works at a different level.  I'm not sure if you'll like it
very much, but I think it will accomplish what you want to accomplish.

What I've done is add two flags.  --suppress-tags takes a comma-separated
list of tags.  --suppress-tags-from-file takes the name of a file listing
tags (or comments).  Any suppressed tags will be treated as if they don't
exist (although they will still be run and the corresponding collect
scripts will still be run, since there's no good way to avoid that).  They
will not be output and will not change Lintian's exit status.

I think this will accomplish what you need by way of:

    lintian --suppress-tags-from-file /path/to/emdebian/suppress <package>

Obviously this can be an alias, like emdebian-lintian.

What this doesn't do is selectively suppress tags based on the version of
the package, of course.  One has to remember to run the emdebian version
of the Lintian alias on the package instead of the regular Lintian.
However, it would be possible to do this in a wrapper that examines the
file names that are being checked and selectively adds that flag based on
the versions extracted from the file names, and that would work in most
cases.

The other advantage of this approach is that it's useful for other
purposes, such as using Lintian to check an internal package repository at
some site that wants to selectively ignore some of Lintian's tags as not
useful for their local policies.

If you don't think this will work for your problem, please do let me know
and we can talk some more about other alternatives, such as a separate
layer of code that can be run before the checks.

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