Re: autopkgtest gating migration, nearly there. But ...

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Paul Gevers writes ("autopkgtest gating migration, nearly there. But ..."):
> Let me describe the problem and the current status.

Thanks.  I am afraid I didn't quite follow your explanation.

> The migration software (britney2) is now taking versioned
> dependencies, breaks and conflicts of the binary packages from the
> source package that wants to migrate into account when requesting
> the tests. It will add versioned dependencies that are not in
> testing and it will add packages from unstable when their version in
> testing is broken by (or conflicts with) anything needed from
> unstable (recursively).

Do you mean that the format of the test request information from
britney2 to ci.d.n has changed ?  IIRC previously it was simply
   ('please run this in testing', <package>, <version_in_unstable>)
for each proposed migration.

Now it is ... what ?

I don't think I can answer the rest of the email unless I know the
answer to this question, but:

> 2) @builddeps@ is not resolved by dpkg-source, so the migration software
> doesn't know if build-depends should be evaluated for the list
> (currently the migration software doesn't add them). (Possibly "fixable"
> by always evaluating them, or possibly fixable by enhancing dpkg-source).

AIUI what you mean here is this:

 * T has tests which Depend on @builddeps@
 * T Build-Depends B
 * The test trigger machinery in Britney (and upstream of Britney
   that calculates Testsuite-Triggers) does not understand that this
   means that T Test-Depends B.
 * Consequently proposed migration of B might not involve
   a rerun of the tests for T with the new B

?

I am reminded of this:

If you declare tests with the needs-build restriction, you will block
the migration of your build-deps when they make your package FTBFS.
But declaring needs-build is said to be undesirable.  There is an
obvious anomaly here.

The anomaly I describe above seems similar.

> 3) test dependencies generated by autodep8 are fully unknown to the
> migration software. It seems (but I haven't verified properly) that e.g.
> with r packages the test dependencies can be versioned as well.

I don't know much about autodep8.  It sounds like maybe autodep8
should be a way to automatically maintain or help maintain
d/t/control, rather than some post-hoc thing.  But I guess everyone
hates committing generated files (which this would imply) too much.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   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.