Re: Dealing with ci.d.n for package regressions
On Fri, 2018-05-04 at 12:08:31 +0100, Ian Jackson wrote:
> 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.
Right.
> 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.
I'm not sure why this is a problem, though? The CI system in use can
easily choose to inject all of foo's dependencies as triggers. And AFAIK
that's already the case?
> 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.
That's no different to so many other fields, which get generated from
other stuff by several tools from the toolchain?
If the desire here is to make it easier to control what gets output,
we could handle this field as we handle the Testsuite one, and append
to it if it already exists in debian/control for example (I'd need to
go back to the original discussion in case we already considered that
but rejected it for some reason), but as you've noticed elsewhere you
can already control it by adding (dummy) entries in debian/tests/control.
> I appreciate that the real reason for this design decision is probably
> that it is difficult to change the software on ftp.debian.org :-/.
The main design decision here, was to avoid needing to unpack the source
packages on the archive side, regardless of what that software might be.
Thanks,
Guillem
Reply to: