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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
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.

(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.

Thanks,
Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

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

Paul Gevers-4
Hi Ian,

Can we carry this discussion over to [hidden email] (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


signature.asc (499 bytes) Download Attachment