Package: dpkg-dev Version: 1.19.1 Severity: wishlist X-Debbugs-Cc: debian...@lists.debian.org
Dear maintainer, From to dsc(5): Testsuite-Triggers: package-list This field declares the comma-separated union of all test dependencies (Depends fields in debian/tests/control file), with all restrictions removed, and OR dependencies flattened (that is, converted to separate AND relationships), except for binaries generated by this source package and meta-dependencies such as @ or @builddeps@. That says that the special value @builddeps@ is ignored for the purposes of the generation of this field. I've come to consider this as a issue, as our testing migration software is not considering build-dependencies as useful (much less needed) triggers for the testsuite (aka autopkgtest, for the purposes of this conversation). I found @builddeps@ useful in multiple occasions, to avoid duplicating —potentially for a third(!) time— a list of packages; but the lack of triggers for those is annoying me, and reducing the usefulness of the testsuite for testing migration purposes. A practical example here could be src:limnoria, at the version 2018.09.09-1. That thing uses @builddeps@ to avoid duplicating packages that are already listed in Build-Depends and in Recommends, but as a result, the tests are triggered very very rarely, only for the direct dependency src:python3-defaults and src:limnoria itself. Informally talking on IRC revealed the following concerns: 1. duplicating the build-dependencies in the triggers has the potential to bloat the Sources index file even more 2. this could be a job better done by the testing migration software, by e.g. always triggering tests for changing build-dependencies, like it already does for changing direct dependencies 3. it would potentially cause useless test runs for things like changed debhelper or other build tools that unlikely would change the run-time behaviour of the software IMHO, concerns 1. and 2. could be taken care of by not expanding @builddeps@ inside Testsuite-Triggers, but instead having it copied as-is, and then the testing migration software would expand it while evaluating the triggers. This would also avoid needless test runs as they would happen as proposed in concern 2. if all packages had their build-dependencies trigger tests (however there is a valid idea here maybe). I also don't think concern 3. is valid: the extra resources used would hardly matter in my opinion. For what my proposal here is concerned, if @builddeps@ end up expanded in Testsuite-Triggers, it should be flattened like the rest of the dependencies listed directly in the Depends field of d/tests/control. -- 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