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 <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
