Thanks Ian for your insight! On Tue, Jul 03, 2018 at 03:59:11PM +0100, Ian Jackson wrote: > My approach is to autogenerate debian/tests/control. I have a rune > which updates it, and a test case which fails when I forget :-). So it seems this is pretty much the only sane way around this. > (In my case debian/tests/control is generated not from debian/control, > but from the test files which contain annotations about their > dependencies, restrictions, etc.) This would also be the case for us. > Tests: hint-testsuite-triggers > Depends: gnupg, patch, diffutils > Restrictions: hint-testsuite-triggers > > The effect of putting something like that in your debian/tests/control > is that autopkgtest will always skip the test, but the Depends get > copied to Testsuite-Triggers and used by ci.d.n. Mh, in our case we have this entry: Tests: pytest Depends: diffoscope, python3-pytest Restrictions: needs-recommends If I go down the route of autogenerating d/tests/control I could simply drop the (as Paul pointed out, unreliable) needs-recommends restriction, and have all the recommends spelled-out in the Depends field. Do any of the diffoscope contributors have any hard feelings on me making d/rules yet longer and implement the above? It would end up with another bit to update whenever a new debian relations in added in the external_tools, even if done semi-automatically... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature