On 2012-10-11 22:42, Jakub Wilk wrote: > * Niels Thykier <ni...@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? >
Mmm, should be doable already by creating/using a "null" profile. Not sure if it should have better built-in support than that... > 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.] > I hadn't considered adding it and I am not sure we should. Though for the "no built-in checks" case it should be trivial to do a L::Output plugin for this purpose. (By trivial I mean L::Output::FullEWI trivial) > 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.] > I think adding them to the standard overrides file will "just work". Do you have a sample lintian4python case where the override fails to work? Or were you thinking we should have a separate overrides file for contrib checks? >> 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... > > [...] > There is that - also we can "always" add it later if it is... ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
