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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)