Ian Jackson writes ("Re: Dealing with ci.d.n for package regressions"):
> I hadn't realissed that _test_ dependencies would trigger retests, as
> well as actual package dependencies.Having read Mattia's message, and looking at the Testsuite-Triggers line which is autogenerated in dgit.dsc, I see that actual package dependencies are not included. That seems wrong to me. foo/debian/tests/control will normally declare a dependency on foo (perhaps by saying `@'); it then won't normally mention all of foo's dependencies. The result of the current behaviour is that regressions introduced by test framework code are more likely to be detected than regressions introduced by ordinary dependencies. Also, and perhaps I should have spotted this earlier: Doing the calculation of Testsuite-Triggers in dpkg-source means that fixing this involves changing dpkg-source on developes' systems. So if I want this to be fixed for my own uploads, from my laptop which is running stretch, I will need to wait for the improved dpkg-source to be in stretch-backports and then update that. It doesn't seem right that the contents of Testsuite-Triggers should depend on the tooling on the uploader's workstation. I appreciate that the real reason for this design decision is probably that it is difficult to change the software on ftp.debian.org :-/. Anyway, I guess I should think about sending patches for dpkg-source ? If someone could point me at the docs for this Testsuite-Triggers construction feature then that would give me a leg up. Thanks, Ian.
