Package: dpkg-dev Version: 1.19.1 Severity: wishlist X-Debbugs-Cc: [email protected]
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
