On Mon, 05 Aug 2024 at 08:52:28 -0400, Reinhard Tartler wrote:
> Consider
> https://ci.debian.net/packages/r/rust-async-executor/testing/amd64/49994925/
>
> Note that this test was triggered to test rust-async-executor 1.12.0-3 (!!)
>
> Here, we see in the part "test rust-async-executor-1:@: preparing
> testbed" (one has to manually expand this, I didn't notice at first):
>
> 31s The following packages have unmet dependencies:
> 31s librust-async-lock-dev : Depends: librust-event-listener-2+default-dev
> 31s E: Unable to correct problems, you have held broken packages.
> 31s autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt
> pinning. Retrying with using all packages from unstable
>
>
> So basically we have uninstallable dependencies. What is worse, however,
> is that the test infrastructure happily continues with installing
> dependencies, all from unstable, *including* the package that triggered
> this test:
>
> 35s Get:166 http://deb.debian.org/debian unstable/main amd64
> librust-async-executor-dev all 1.13.0-2 [20.0 kB]
>
> Basically the infrastructure was asked to test one thing (i.e.,
> rust-async-executor 1.12.0-3), but ended up testing something different
> (i.e., librust-async-executor-dev_1.13.0-2), and then declaring the test
> failed
I think we probably have to treat this as a bug in "larger" infrastructure
(debci? britney?) that is blocked by an autopkgtest feature request, rather
than an autopkgtest bug in itself.
It's clearly wrong that we were aiming to test 1.12.0-3 but
ended up running its tests against 1.13.0-2; but at the same time,
autopkgtest doesn't know that it's unacceptable to install binaries
from rust-async-executor at a version other than 1.12.0-3 unless someone
says so.
To avoid this, I think it would have to grow a new command-line
option to tell it something like: "pin all binary packages from
src:rust-async-executor to source version 1.12.0-3, at a high priority".
A complicating factor is that the version number of binary packages is
not always trivially derivable from the version number of the source.
Consider binNMUs, but also packages like libreoffice where source package
libreoffice_4:24.2.5-1 builds binary package
fonts-opensymbol_4:102.12+LibO24.2.5-1 (note the version prefix).
smcv
