Hi, On 05-04-2025 16:33, Peter Green wrote:
Is there something I can improve on this front? In other words, how can the design become smarter?It's hard to answer this because I don't really understand exactly how the scheduler works, but what I frequently see is. 1. The set of pins that britney chooses don't work. 2. The fallback dependency solver is invoked, this successfully installs the packages, but causes a mismatch between the tests (taken from testing) and the package under test (taken from unstable due to the fallback dependency solver). 3. The mismatch between tests and package under test causes a failure. This often happens in complex dependency graphs, where some but not all of the dependencies in the graph are broken by the update. or where some dependencies exist in unstable but not in testing or vice-versa. We can often workaround this by tightening dependencies or adding breaks but each time we do that it resets the tests and the migration delay time, it can also tie together the testing migration of things that do not need to be tied together. I don't know how exactly britney choses what packages to pin, but it often falls short of the set of "packages that must migrate together according to the recursive interpretation of the "migrates after"/"blocked by" in the excuses.
I suspect this is related to the heavy use of Provides in the rust ecosystem. I suspect that what's missing is the logic (potentially only in the autopkgtest policy, but maybe in all policies) to treat a src:package that is the sole provider of a certain Provides similar like it would treat the source of a real binary of that name.
That indeed is already long time on my TODO list to investigate (and fix if I'm right), but I never had the tuits to start on it.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
