Hi, On 12/15/25 00:03, Peter Green wrote:
Just how recent were these changes? If they were very recent I may not have had enough time to notice them.
I didn't have specifics in mind, just some of my work since you filed the bug.
The situation over the last year or two seems to be that the autopkgtest scheduler has some understanding of versioned provides, but only *after* all builds are complete, if builds are missing the changes in versioned provides are ignored.
Right.
There are also problems in more complex scenarios. Based on my obvervarions of britney's behaviour and the assumption that the first package in the "trigger" list is the one that actually triggered the test. the simplest scenario which I'm pretty sure fails (or at least failed as-of a few weeks ago) is where you have packages like. * A depends on B through a versioned provides * A depends on C through a versioned provides * B depends on C through a versioned provides C removes a versioned provides and adds a new one (usually as a result of a rust semver bump). A and B are adapted to the new version of C but A's dependency on B remains unchanged.
I created a test case in the test suite for this [1].
Once all the builds are in A and C will trigger autopkgtests of A with the new versions of A and C but not the new version of B. This will likely trigger the fallback depsolver in debci but will generally pass.
Yes, currently it does, but it *also* triggers tests from A, B and C with all three packages from unstable (triggered by C).
A more subtle variant.of this comes if A bumps it's dependecy on B as part of the update. In this case the autopkgtest of A triggered by A correctly includes all three packages and passes. but the autopkgtests of A triggered by B and C are still "wrong". If no follow up updates are needed this doesn't matter, the autopkgtest triggered by A overrides but if follow-up uploads are needed this can become a problem.
Also this test case (in the variants directory) doesn't work as you describe.
Can you please check the test cases (the Packages_i386 and Sources files in var/data/(unstable|testing) and try to find where I didn't understand you correctly?
Paul [1] https://salsa.debian.org/debian/britney2-tests/-/commit/29d8220
OpenPGP_signature.asc
Description: OpenPGP digital signature
