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

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



This is a reply to a message from last May that I'd set aside at the time
because I wanted to think about it, and then it got buried in my to-do
list for all this time.  Sorry about that.  I've been thinking about it
off and on since then, at least.

Stefano Zacchiroli <zack@debian.org> writes:

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

I think you're right, and I agree that it's hard in many cases to do those
tests without using the infrastructure of the language being tested.

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

I like this idea.  I was considering whether plugin packages should just
drop additional checks into Lintian's regular directory, but I like the
idea of reproducibility being the default.

There's already a wishlist bug against Lintian, which I intend to work on
at some point in conjunction with overhauling Lintian's configuration and
the code that processes the configuration file, to allow the default flags
for Lintian to be set in Lintian's configuration file.  I think that's an
obvious enhancement and it would let you configure Lintian to enable that
option by default, either in your home directory or in a system-wide
configuration file if you wish.

The alternative to something like this is for each team to write their own
checks in a separate Lintian root, which requires a lot of duplication of
effort to set it up, or to write a completely separate package checking
tool specific to the team.  And the last seems like a waste of effort if
Lintian would work.

This same system could also be used to add checks that, while they may be
fine from a dependency perspective, are team-specific and hence not
suitable for Lintian itself.  For example, a team could write a custom
module to check that the package maintainer is set correctly for their
team and then enable that module with a Lintian command-line flag when
checking packages for their team.

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

Yes, I think this is a great idea.  That way, members of multiple teams
can selectively enable the modules they want to use for the package
they're currently checking, which lets the teams write very simple macros
for doing things like the above-mentioned maintainer check without needing
to figure out if that package applies to that particular team.

My inclination is therefore to remove wontfix from #359059, which is a
related bug asking for a facility to load custom checks from .lintian, and
to use that bug to track the addition of this sort of module system.

What do the other Lintian maintainers think about this?

One nice property of a check-based module system is that a module can then
drop in additional collection scripts as needed without having to do
anything special for them, since they'll be picked up or not automatically
based on whether any modules in play use them.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: