Hi Ian,
Can we carry this discussion over to debian-ci@lists.debian.org (added
in CC now)?
On 04-05-18 15:24, Ian Jackson wrote:
> James Clarke writes ("Re: Dealing with ci.d.n for package regressions"):
>> On Fri, May 04, 2018 at 11:55:56AM +0100, Ian Jackson wrote:
>>> Is that documented somewhere ? I can't find it here
>>> https://manpages.debian.org/stretch/dpkg-dev/dpkg-source.1.en.html
>>> https://manpages.debian.org/stretch/dpkg-dev/deb-src-control.5.en.html
>>
>> It's in the .dsc, so you want dsc(5) :)
>
> Ah, thanks. Looks like there is no way to control it from the source
> package. There is a difficulty with implementing that. The
> Test-Triggers ought to mention autocomputed dependencies. Eg, if we
> have
>
> foo/debian/tests/control
> Depends: @
>
> foo/debian/control:
> Build-Depends: libbar-dev
> Depends: ${shlibs:Depends}, ${misc:Depends}
>
> foo.deb:
> Depends: libbar1 (>= 1.2-0)
>
> then we should have
>
> Testsuite-Triggers: libbar1
>
> This can't be computed from the source package because it depends on
> the version of libbar-dev. It can't even be computed as source upload
> time.
>
> I think therefore that tests should be triggered based, additionally,
> on binary package dependencies as found in the archive. For every
> binary package B which is produced by a source package S and depends
> on another binary package D: tests of S should be retriggered for
> updates to D. "Depends on" would probably mean "is mentioned as first
> alternative in any Depends on Recommends requirement". This can be
> determined from the published metadata without unpacking any source
> packages or looking at Testsuite-Triggers.
Let me ponder on this a bit more.
> (In theory this should only be done for binary packages B which are
> not only generated by S but also mentioned, perhaps by virtue of `@',
> in the Depends on a test of S. This could be determined from
> Testsuite-Triggers except that Testsuite-Triggers is specified to
> exclude @ish dependencies.)
>
> Arguably the test triggers from Depends in debian/tests/control are
> less important and could even be dropped. But in any case dpkg-source
> should have explicit way to control or supplement.
> Testsuite-Triggers.
>
> I'm happy to write a patch to do the latter. I'm not sure where I
> would start with the former but I would be willing to give it a go if
> someone would point me in the right direction.
The code to calculate which packages are triggered lives here:
https://salsa.debian.org/release-team/britney2/blob/master/britney.py
(bfa02859 Line 334-340)
Paul
Attachment:
signature.asc
Description: OpenPGP digital signature