Re: autopkgtest gating migration, nearly there. But ...
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 Jackson <firstname.lastname@example.org> 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.