Re: Dealing with ci.d.n for package regressions
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.
Reply to: