Bug#779559: dpkg-source: Add test dependencies to .dsc

[Guillem Jover]

Hi!

On Wed, 2015-03-04 at 10:06:42 +0100, Martin Pitt wrote:
> Guillem Jover [2015-03-04  9:57 +0100]:
> > But then, the test runners will need to parse the specific test case
> > dependencies, as in this case @ is omitted, so we might as well just
> > coalesce any other dependencies in the same field. Hmmm.
> 
> Correct, the field is fairly useless for autopkgtest itself (or
> similar implementations); not only because of the missing @ or
> @builddeps@, but also because it's just the union of all dependencies
> of all individual tests. I. e. if you have
> 
>   Tests: foo
>   Depends: foo1, foo2
> 
>   Tests: bar
>   Depends: @, bar1
> 
> then Testsuite-Depends: will be "foo1, foo2, bar1".
> 
> So maybe there is a better field name to express the intended meaning.
> We don't want it as a primary specification of test deps (that's still
> in debian/tests/control or on another place for different kinds of
> package tests), just as an indication to "run the tests for this
> package if any of these listed packages changes". So something that
> expresses XS-Run-Tests-When-Packages-Change: ..  Perhaps
> 
>   XS-Testsuite-Triggers:
> 
> ?

Ah, indeed, making it clear that this is strictly not for "dependency"
purposes, seems better. It just crossed my mind that it might make sense
to strip the version information from those dependencies, and only list
package names, but given that those dependencies can have alternatives
«foo (>= 1.0) | bar», they should probably be preserved?

> It's even conceivable that package maintainers want to maintain this
> field manually, like "run the tests for the nvidia graphics driver
> whenever the kernel changes". But auto-generating it in the described
> manner would still be an useful default IMHO.

Right. So then we either need to replace it with the information
from the testsuite, or extend it in a similar way as how the Testsuite
field is currently being handled. I'd tend to think the latter.

> > The problem with this is that, if in the future we require the
> > information to be distinct, that's pretty hard to detangle. Merging
> > it, is pretty easy because it can be done at run-time while source
> > packages get rebuilt.
> 
> You mean distinct per individual test-case (see above)? If you mean
> something else, then I don't understand, I'm afraid.

When I said coalesce any other dependencies I was thinking about the
following situation. Say we have a package with an "autopkgtest"
testsuite with dependencies «foo (>= 1.0), bar», and another "newchecks"
testsuite with dependencies «quux, frob, bar». And then the
Testsuite-Triggers ends up being «foo (>= 1.0), bar, quux, frob».

If I'm only interested in running either autopkgtest or newchecks for
the whole archive, I might get triggered for packages that I'm not
interested in, which would be wasteful. And to get accurate
information we are back to having to unpack the source packages. This
might get worse the more testsuites we get.

(But in any case this is all very hypothetical, because we might
possibly never get a new testsuite alternative, but I like to think
ahead of time, and consider all these "corner-cases" before they
possibly bite us.)

Thanks,
Guillem