Bug#359059: lintian: Allow vendor/user specific checks
Package: lintian
Version: 2.5.10.1
Followup-For: Bug #359059
Long ago, Russ Allbery may have written:
> [...]
>
> 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.
>
I agree with this and I believe lintian4python is an example of this.
> > 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.
>
I think "reproduciability by default" is probably the best choice, though
I am okay with adding a configuration variable in ~/.lintianrc to load
certain contrib checks by default.
> [...]
>
> 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.
>
I have devised a prototype implementation[1], which should demonstrate how
this could be implemented with relatively few changes on top of the master
branch.
In the prototype,
1 the command line argument is "--contrib-check X"
2 if $CHECKS/contrib/X.desc is a file or symlink, then that is loaded
3 if $CHECKS/contrib/X is a dir (or symlink to a dir), all checks in
that dir is loaded (but no recursion is done).
(More or less a "$CHECKS/contrib/X/*.desc")
4 $CHECKS is one of (in order):
- ~/.lintian/checks
- /etc/lintian/checks
- LINTIAN_ROOT/checks (usually /usr/share/lintian/checks)
(NB: Yes, this means you can "shadow" a built-in check)
2+3 together allows providers to split their check into multiple
files (or merge multiple files into one) without users needing to know
or care about it.
> 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?
>
I am positive about this idea.
> 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/>
>
FTR, the prototype only loads collections from LINTIAN_ROOT/collections.
Do we want to add a "contrib" dir in collections/ as well? Personally
I think it would be a good idea as then we (i.e. Lintian maintainers)
don't have to worry about name conflicts with contrib modules.
A couple of open questions:
* Where do contrib checks install their data files?
A suggestion could be:
<root>/vendors/contrib/<X>/...
and have Lintian special case it.
* What part of the Lintian::Collect (or Lintian::* for that matter)
is considered "API" and what is our policy on updating/breaking
API?
* If a contrib module wants to install its own collection, how will
it extend the relevant L::Collect module?
- Something tells me that packages providing collections will likely
also (eventually) be using it from multiple checks.
~Niels
[1] http://anonscm.debian.org/gitweb/?p=users/nthykier/lintian.git;a=shortlog;h=refs/heads/local-checks
diffstat for those 3 commits:
frontend/lintian | 32 +++++++++++++++++++++++++-------
frontend/lintian-info | 17 +++++++++++++++--
lib/Lintian/CheckScript.pm | 3 ++-
lib/Lintian/Data.pm | 14 ++++----------
lib/Lintian/Profile.pm | 164 [...]
man/lintian-info.pod | 5 +++++
man/lintian.pod.in | 5 +++++
reporting/html_reports | 3 +--
t/scripts/tags.t | 4 ++--
t/tests/binaries-hardening/test_calibration | 4 ++--
10 files changed, 188 insertions(+), 63 deletions(-)
Reply to: