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 `-
signature.asc
Description: PGP signature
