[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question: trigger autopkgtests with packages that are not in the dependency chain



On Mon, 16 Jan 2023 at 10:47:27 +0700, Arnaud Rebillout wrote:
> In Kali Linux, I have a package named kali-tweaks, it provides an UI to
> configure different components of the system. For example, it allows
> configuring the SSH client. It does NOT depend on openssh-client, however I
> would like to trigger autopkgtest when the package openssh-client changes.
> How can I achieve that?

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
kali-tweaks.deb?

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. 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
https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst:

    Tests: hint-testsuite-triggers
    Depends: hello, init, openssh-client
    Restrictions: hint-testsuite-triggers

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.

    smcv


Reply to: