Not every rule is going to be universally applicable. There will always be room for exceptions. However, coding these exceptions directly into the lint checks isn't going to scale very well and may very well impact performance.
Instead, a way to let lintpkg know that a certain warning/error is not applicable is preferable. Still, they shouldn't be hidden completely. There should still be a way to see those warnings/errors, if one wants.
The override functionality from lintian is a pretty close match to that behavior. The idea would be to introduce a /usr/share/lintpkg/overrides directory holding override information per package. The content of such a file would look like this:
# Binary needs to retain debugging info to be useful:
foo: unstripped-binary /usr/bin/foo
As a start, every file affected should be listed. We can introduce support for wildcards later.
Not every rule is going to be universally applicable. There will always be room for exceptions. However, coding these exceptions directly into the lint checks isn't going to scale very well and may very well impact performance.
Instead, a way to let
lintpkgknow that a certain warning/error is not applicable is preferable. Still, they shouldn't be hidden completely. There should still be a way to see those warnings/errors, if one wants.The override functionality from
lintianis a pretty close match to that behavior. The idea would be to introduce a/usr/share/lintpkg/overridesdirectory holding override information per package. The content of such a file would look like this:As a start, every file affected should be listed. We can introduce support for wildcards later.