Re: Bug#498138: check for deprecated OCaml -custom linked executable
- To: "Stefano Zacchiroli" <firstname.lastname@example.org>, <email@example.com>, "Russ Allbery" <firstname.lastname@example.org>
- Cc: "Debian Ocaml Maint ML" <email@example.com>
- Subject: Re: Bug#498138: check for deprecated OCaml -custom linked executable
- From: "Adam D. Barratt" <firstname.lastname@example.org>
- Date: Tue, 12 May 2009 17:46:18 +0100
- Message-id: <D352E4867E48414B93DDAB576C99F3B4@andromeda>
- 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>
[ replying to Russ' post, which contains the interesting part to
support Stephane's reply ]
I'm not Russ, obviously, but fwiw with my Lintian co-maintainer hat on...
In this particular case it will be /usr/bin/ocamlobjinfo. The lintian
test will do nothing, silently, if the executable is not
there. (Alternatively, it can emit a warning or an info message if the
package is recognized to be OCaml-related and ocamlobjinfo is not
Russ: what would you think of that?
My initial thought is that doing so would break reproducibility of Lintian
results. Maintaining that reproducibility is a reasonably common reason for
requests for checks which rely on data or services external to Lintian to
end either being made wontfix, or closed.
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.
There isn't an API as such, but Lintian largely globs the contents of
/usr/share/lintian/checks so there's nothing technically stopping packages
dropping scripts in there, subject to namespace collision. There's an
emdebian specific check file, but I'm not sure whether they're actually
shipping it anywhere.
However, I've just spotted #359059 where Russ suggests either integrating
the checks in to Lintian or using a copy of Lintian with an alternative
root, again for reproducibility.