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

Martin Pitt mpitt at debian.org
Wed Mar 4 09:06:42 UTC 2015

Hey Guillem,

Guillem Jover [2015-03-04  9:57 +0100]:
> Heh, that reminds me a bit of
> <http://www.hadrons.org/~guillem/debian/docs/test.proposal>.

Wow, 2006! :-)

> In any case, yeah, this sounds fine. I've conflicting thoughts about
> the field name, on one hand Testsuite-Depends (to match the existing
> field) seems nicer and more neutral, on the other it would take over
> that field for a specific testsuite implementation, as the Testsuite
> field already supports different values, even at the same time.

Indeed XS-Testsuite-Depends: would match Testsuite: better. Other test
implementations could use that as well, though?

> 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



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.

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


Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

More information about the autopkgtest-devel mailing list