Hi, On 10-10-18 19:56, Guillem Jover wrote: >> 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.
britney2 in Debian would only need @builddeps@ (but I don't mind it being more generic and having @ as well). I'll can fix this soon. I suppose you would want to just transfer the full set of test dependencies to Test-Trigger. (Slightly of topic, that would make the problem of "needs-recommends" also simpler, because then we could migrate to a @recommends@ syntax and define that properly). britney2 in Ubuntu is not at all in sync with Debian nowadays, so Ubuntu needs to be informed and they need to adapt as well. I don't know of other parsers. Paul
signature.asc
Description: OpenPGP digital signature
