Hi Ian,
Thanks for replying.
On 17-09-18 15:52, Ian Jackson wrote:
> 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.
Great. Well, not that you don't follow, but that at least you tell me
that I failed to convey my message.
>> 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 ?
No, not at all.
> IIRC previously it was simply
> ('please run this in testing', <package>, <version_in_unstable>)
> for each proposed migration.
It's slightly more, ('run this in testing', <package>, <with the
following from from unstable: src:1, bin_pkg2, src:2>)
> Now it is ... what ?
The same. So, what I meant above was that I britney started to extend
the list from "src:1", to "src:1, src:2, src:3" if binaries from src:2
and src:3 are needed to satisfy dependencies of the test of package with
binaries from src:1 from unstable. E.g. because the binaries of src:1
have a versioned dependency or because binaries of src:1 have a
versioned breaks or conflicts relation with the test dependencies from
package. What changed in autopkgtest is that I disabled (on the Debian
infrastructure) the apt-get fall back where everything from unstable
would be allowed.
> 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.
Indeed, because in the current data processed by britney this knowledge
is lost.
> * Consequently proposed migration of B might not involve
> a rerun of the tests for T with the new B
This is indeed an issue, but not the one I am discussing here. What I
mean is that britney doesn't know that it needs to check if binaries
from src:1 break/conflict the versions of B in testing, while the
version of B from unstable would be OK (recursively).
> 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.
It's not totally clear to me what you are getting at.
>> 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.
One solution could be that indeed instead of running autodep8 from
autopkgtest, packages should run it while creating the Debian source.
Apart from committing generated files, another drawback of that is that
when autodep8 gets enhanced, the adoption rate is much lower. Currently,
once autodep8 migrates, every package that falls in the enhanced class
of packages, gets the better test. Image we find a way to test Python
package better than the current poor man's solution of just importing
the module that matches the Python package name (there were idea's on
debian-devel some months ago), we want all Python packages that opted
for autodep8 to do that (instead of continuing to only test importing
modules).
Paul
Attachment:
signature.asc
Description: OpenPGP digital signature