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

[PATCH 2/3] autodetect Perl packages

On Mon, Sep 08, 2014 at 04:04:14PM +0200, Martin Pitt wrote:
> Niko Tyni [2014-09-08 14:49 +0300]:

> > The "runtime-deps" tests do much less because it's hard to come
> > up with other generic tests there apart from "use Some::Module".
> So that one isn't actually supposed to run any upstream tests, but
> just check that you can load the module? This should indeed spot
> missing binary depends.

Right, that's the idea.

Possibly use.t could also do something like
 use Module; 
 Module->new if Module->can('new');
which might exercise OO modules and their dependencies a bit deeper. Not
sure how much difference that would actually make though - I suspect
the new() methods are generally rather trivial.

We also have a syntax.t test in the 'runtime-deps' set that checks that
none of the .pm files installed choke with 'perl -c'. That might trigger
failures with some packages that only load part of their modules if a
package in Recommends: is installed. We'll see how much of a problem this
is; it should be easy to add support for a package-specific blacklist
in the test if necessary.

As future expansion, I'm thinking of using valgrind and/or some sort
of a memory leak tester in the heavy-deps tests, maybe invoking
Module->new a hundred times and checking that the memory usage
doesn't grow too badly. We've seen a few of such memory leaks over the
years. Test::Memory::Cycle also looks interesting...

But the results from the current implementation clearly have priority :)
Niko Tyni   ntyni at debian.org

Reply to: