Re: Bug#498138: check for deprecated OCaml -custom linked executable
- To: firstname.lastname@example.org
- Subject: Re: Bug#498138: check for deprecated OCaml -custom linked executable
- From: Sylvain Le Gall <email@example.com>
- Date: Wed, 13 May 2009 19:47:48 +0000 (UTC)
- Message-id: <firstname.lastname@example.org>
- References: <48A85223.email@example.com> <48A9996A.firstname.lastname@example.org> <20080820115120.GD12295@yocto.gallu.homelinux.org> <48AC33CE.email@example.com> <20080907130757.GA23516@usha.takhisis.invalid> <48C3EA5B.firstname.lastname@example.org> <20080907150900.GD29886@usha.takhisis.invalid> <email@example.com> <20090512141619.GA15918@usha.takhisis.invalid> <D352E4867E48414B93DDAB576C99F3B4@andromeda> <20090513164523.GC32112@usha.takhisis.invalid>
On 13-05-2009, Stefano Zacchiroli <firstname.lastname@example.org> wrote:
> On Tue, May 12, 2009 at 11:08:37AM -0700, Russ Allbery wrote:
> However I see a difference on scope. We, Debian OCaml Maintainers,
> want a tool to run our own tests, use it for our own team-specific QA,
> and give it to our packagers as a tool to run pre-upload. What if
> lintian gets a --enable-plugins flag (name is totally random) which is
> *not* the default and which makes it look for plugins installed in an
> extra directory where add-on packages can drop tests? Say:
> /usr/share/lintian/checks/contrib/ , where dh-ocaml will drop its own
>=2Epl files. Additionally, I'd like to have a way to configure my
> lintian so that that option is enabled by default for me (and for
> other d-o-m packagers).
> That way lintian results will be reproducible, unless you explicitly
> ask for. I think the "team culture" of Debian can benefit a lot from
> such an improvement.
> Bonus idea: instead of a "global" enable-plugin system, we can go for
> --with-plugin=3Docaml, --with-plugin=3Dpython which will make lintian look
> in some ocaml/ and python/ subdir so that multiple plugins do not step
> on each other toes implicitly.
This is also a good "first step" for creating lintian test. For example,
OCaml team know quite well its programming language (OCaml) and the
problem that comes with. We know how to do QA and what tools we need.
Doing a quick prototype with the tool we have (e.g. ocamlobjinfo) is a
way to create a coherent set of test which are perfect to fit OCaml
needs. Once everything is done and running for a time, we can think to
migrate this test by not replacing specific tools (like ocamlobjinfo).
The point is that using external tools breaks reproductibility but helps
to design the test we want (e.g. quick and dirty at the beginning and
This kind of "external plugin" architecture can be a very good way for
packaging team to enhance their policy and their QA.
Sylvain Le Gall