Re: Bug#498138: check for deprecated OCaml -custom linked executable
- To: Debian Ocaml Maint ML <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: Bug#498138: check for deprecated OCaml -custom linked executable
- From: Russ Allbery <email@example.com>
- Date: Tue, 12 May 2009 11:08:37 -0700
- Message-id: <firstname.lastname@example.org>
- In-reply-to: <20090512141619.GA15918@usha.takhisis.invalid> (Stefano Zacchiroli's message of "Tue\, 12 May 2009 16\:16\:19 +0200")
- References: <20080907150900.GD29886@usha.takhisis.invalid> <4A097B75.email@example.com> <48A85223.firstname.lastname@example.org> <48A9996A.email@example.com> <20080820115120.GD12295@yocto.gallu.homelinux.org> <48AC33CE.firstname.lastname@example.org> <20080907130757.GA23516@usha.takhisis.invalid> <48C3EA5B.email@example.com> <20080907150900.GD29886@usha.takhisis.invalid> <firstname.lastname@example.org> <20090512141619.GA15918@usha.takhisis.invalid>
Stefano Zacchiroli <email@example.com> 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
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 (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>