Package: lintian Version: 2.5.10.1 Followup-For: Bug #359059 Long ago, Russ Allbery may have written: > [...] > > Stefano Zacchiroli <[email protected]> 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 ([email protected]) <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(-) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
