[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#498138: check for deprecated OCaml -custom linked executable

On Tue, May 12, 2009 at 05:46:18PM +0100, Adam D. Barratt wrote:
> I'm not Russ, obviously, but fwiw with my Lintian co-maintainer hat
> on...

Thanks to both Adam and Russ for the clear answers.

> 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.

This is the clear counter-argument emerging from both your replies; I
wasn't aware of that.

On Tue, May 12, 2009 at 11:08:37AM -0700, Russ Allbery wrote:
> 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.

This tension is clear as well. Still, I believe that inhibiting
macro-areas of Debian to have their own tests is too constraining in
general. I can imagine tons of examples where various packaging
groups---especially language-specific packaging areas such as OCaml,
but also Python, Haskell, Java---can benefit of their own tests and I
don't want to give up on that possibility.

So let me try to propose an alternative solution. It is based on the
assumption that *by default* people want reproducibility; I understand
this principle: if we use lintian to do QA, its answers should be
reliable, and non-reproducibility is unreliability.

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
.pl 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=ocaml, --with-plugin=python which will make lintian look
in some ocaml/ and python/ subdir so that multiple plugins do not step
on each other toes implicitly.

Just throwing an idea in the basket ...

Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

Attachment: signature.asc
Description: Digital signature

Reply to: