On Wed, Oct 10, 2018 at 07:56:39PM +0200, Guillem Jover wrote: > 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.
yeah I don't think dpkg should expand those. > 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. yes please. > 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. A quick look at codesearch¹ does not show any parsers in the archive so far. ¹ https://codesearch.debian.net/search?q=Testsuite-Triggers
signature.asc
Description: PGP signature
