Bug#359059: lintian: Allow vendor/user specific checks
* Niels Thykier <niels@thykier.net>, 2012-09-17, 13:49:
I have devised a prototype implementation[1], which should demonstrate
how this could be implemented with relatively few changes on top of the
master branch.
In the prototype,
1 the command line argument is "--contrib-check X"
2 if $CHECKS/contrib/X.desc is a file or symlink, then that is loaded
3 if $CHECKS/contrib/X is a dir (or symlink to a dir), all checks in
that dir is loaded (but no recursion is done).
(More or less a "$CHECKS/contrib/X/*.desc")
4 $CHECKS is one of (in order):
- ~/.lintian/checks
- /etc/lintian/checks
- LINTIAN_ROOT/checks (usually /usr/share/lintian/checks)
(NB: Yes, this means you can "shadow" a built-in check)
2+3 together allows providers to split their check into multiple files
(or merge multiple files into one) without users needing to know or
care about it.
Will there be a way to run _only_ contrib checks, i.e. skip the ones
from lintian proper?
Will there be a visual indication that an emitted tag comes from a
contrib check? [lintian4python uses e:/w:/i:/p:/x: instead of
E:/W:/I:/P:/X:, so that its output can't be easily confused with
official lintian output.]
How will overrides play with contrib checks? [I had a user who wanted to
add an override for lintian4python, though there's currently no way to
do that.]
FTR, the prototype only loads collections from LINTIAN_ROOT/collections.
Do we want to add a "contrib" dir in collections/ as well? Personally
I think it would be a good idea as then we (i.e. Lintian maintainers)
don't have to worry about name conflicts with contrib modules.
I haven't thought thoroughly about it, but my gut feeling is that
allowing 3rd-party collections would open a can of worms...
A couple of open questions:
* Where do contrib checks install their data files?
A suggestion could be:
<root>/vendors/contrib/<X>/...
and have Lintian special case it.
Sounds good to me.
--
Jakub Wilk
Reply to: