[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dealing with ci.d.n for package regressions

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:
(bfa02859 Line 334-340)


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: