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
XS-Testsuite-Triggers:
?
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.
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
More information about the autopkgtest-devel
mailing list