Re: Question: trigger autopkgtests with packages that are not in the dependency chain
On 16/01/2023 17:16, Simon McVittie wrote:
If one of the autopkgtest stanzas in debian/control has
Depends: openssh-client, then that's treated as a dependency for debci's
purposes. I assume you will need to install openssh-client in order
to test this reconfiguration, even if it isn't a dependency of
Indeed! didn't realize it was that simple.
The implementation is that dpkg-source reads the test dependencies out of
debian/tests/control and copies them into the Testsuite-Triggers field,
which ends up in the Sources index.
Indeed, I can see this field in the .dsc of my package, after adding
For example, take a look at src:dbus,
which does not (build-)depend on apparmor, gnome-desktop-testing or xvfb,
but does list them in its Testsuite-Triggers as a result of them being
mentioned in debian/tests/control; so the dbus test suite will be re-run
whenever apparmor changes.
Or, if the dependency is indirect or you are doing something unexpected,
you can add a stanza like this to debian/tests/control, as documented for
the "hint-testsuite-triggers" restriction in
Depends: hello, init, openssh-client
and that will get your test re-run every time hello, init or openssh-client
is changed, but without actually installing those packages.
The name of the test script hint-testsuite-triggers is arbitrary, and
I don't think it actually needs to exist. It will never be run, because
of the Restriction. However, its dependencies will still be copied into
the Testsuite-Triggers as though it *was* going to be run. For example,
look at src:apparmor, which has a hint-testsuite-triggers stanza to get
its tests re-run every time there's a new kernel available.
Thanks for all the details and examples Simon, it's very helpful.