Hi! On Wed, 2018-10-10 at 15:34:02 +0200, Mattia Rizzolo wrote: > Package: dpkg-dev > Version: 1.19.1 > Severity: wishlist > X-Debbugs-Cc: debian...@lists.debian.org
> 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. Ah, I think I might have misunderstood your original issue when reported on IRC. I see that the problem is the omission of those values from the generated field. > 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. I think expanding the @ and @builddeps@ markers would not be ideal, because that its loses semantic meaning. And makes the job of the reader harder, by having to possibly infer (although that might end up being wrong), whether the listed dependencies are the ones coming from the build-dependencies or from the binary packages or similar. I think that if we want to expose these, they should just be exposed as is, and accepted by any parser. They then can decide whether to honor these values or ignore them easily. This would need someone to hunt down and audit any parser, file bugs and block this one on them. Once the parsers have been updated, we could make dpkg-source let these through. Thanks, Guillem
