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

[Guillem Jover]

Hi!

On Wed, 2015-03-04 at 11:00:08 +0100, Martin Pitt wrote:
> Guillem Jover [2015-03-04 10:42 +0100]:
> > 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?
> 
> Stripping versions sounds good to me. For alternatives I'd either
> split them out as separate triggers (if we want to trigger tests on
> alternative changes too), or just ignore them completely (if we don't
> want the extra test runs).

Ok, if we just want a list of packages that should trigger test reruns
then yes, splitting alternatives and stripping versions would be best,
because having thought about it, I think it does make sense to trigger
on changes for the alternatives too (and ideally the test runner would
then use, if satisfiable, the alternatives that have changed!).

> > > 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.
> 
> I'd say, if debian/control already has that field, dpkg-source
> shouldn't touch it at all. That way you can avoid unnecessary reverse
> dependency runs if the maintainer decides so?

Ok, this gives more control, as it allows to reset the field. If the
maintainer wants to extend it, those can always be added to some of
the specific test dependencies instead.

On Thu, 2015-03-05 at 06:34:31 -0700, Adam Conrad wrote:
> On Wed, Mar 04, 2015 at 10:42:15AM +0100, Guillem Jover wrote:
> > 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».
> 
> I'm not convinced this is actuall a problem.  What we're trying to
> approximate here with auto-filling Testsuite-Triggers (rather than
> someone specifying it manually in debian/control) is a set of packages
> that we feel it would be reasonable to force a retest for.
> 
> Sure, maybe it wastes a few cycles if TestA doesn't actually depend
> on or use DepB, but we run it when DepB changes anyway, but I'm not
> sure optimising for that is worth having ${test}-Triggers instead of
> just one concatenated field.

Ok, that makes sense. Also considering it an approximation doesn't
disallow the test runner to skip the package by checking the more
fine-grained dependencies from the test metadata, even for different
testsuite implementations.

On Wed, 2015-03-04 at 11:00:08 +0100, Martin Pitt wrote:
> On Wed, Mar 04, 2015 at 10:42:15AM +0100, Guillem Jover wrote:
> > 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.
> 
> OK, agreed. So putting that together, how about:
> 
>   XS-Autopkgtest-Triggers: foo, bar, baz
> 
> which gets the union of all test depends, minus @, without versions,
> and with alternatives either expanded or ignored?

So given all the above, I'd say:

  Testsuite-Triggers: foo, bar, baz

from the union of all testsuites test depends, minus @ and @builddeps@,
without versions, and with alternatives split (i.e. a simple comma
separated package list). If the field is present then it overrides the
automatically extracted value.

Does this seem fine?

Thanks,
Guillem