Stefano Zacchiroli <[email protected]> writes: > That, to me, looks like *a* possible way of implementing that. Before > going forward however, I'd like to have Lintian's maintainer approval > on the strategy. What we are proposing is a conditional lintian check, > to be implemented in Perl as usual, but relying on an executable which > is *not* granted to be there by lintian dependencies.
One of the general maintenance rules we've tried to follow with Lintian is that anyone who runs the same version of Lintian on the same package gets the same results. This is helpful for lintian.d.o as well as for general reproducibility of problems. There's always a tension between this and doing custom checks for particular portions of Debian, such as this one. We've never found a good resolution to it for cases where it doesn't make sense for Lintian to use a pure-Perl heuristic. > More generally though, I believe we have an interest in adding > OCaml-specific checks to lintian. Is there an alternative way, such as > a plugin system supporting external Lintian tests? It would be very > interesting for us to ship them via our dh-ocaml package, and I'm > confident other packaging communities will be interested in doing the > same for their pet packages. That's exactly my concern -- that we'll end up with a bunch of separate customizations of Lintian that do additional checks, none or few of which will represented on lintian.d.o, and we'll end up in a rather confusing situation. One possibility, although it's not as nice for you as just adding things to Lintian, is that the Lintian front-end can use an alternative root directory. You could write a lintian-ocaml wrapper that points to an alternative root that symlinks the unpack and collection directories and then runs a set of custom checks that do just the Ocaml-specific stuff, and run both regular Lintian and your wrapper on Ocaml packages. I'm not sure if I really like that idea, though.... -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
