Hi Simon, On 27-02-2020 22:27, Simon McVittie wrote: > On Thu, 27 Feb 2020 at 20:02:10 +0100, Paul Gevers wrote: >> Starting 2 pkgProblemResolver with broken count: 1 >> Investigating (0) autopkgtest-satdep:amd64 < 0 @iU mK Nb Ib > >> Broken autopkgtest-satdep:amd64 Depends on libdbusada0.5.0:amd64 < none >> @un H > > > Right, I understand that, after we have decided to run the d/tests/ from > the dbusada source package from unstable rather than testing, we run into > dependency resolution failures for *binary* packages (which in this case > we can't solve). That's fine. > > What I didn't expect is that we are trying to test the dbusada *source* > package from unstable - I would have expected that for migration testing, > we would want to download the source package from testing, and run its > d/tests/, instead (like we did for the migration reference)? Aha, wait, I overlooked the part where the source was already picked from unstable. The autopkgtest code has this: """ # The default is to determine the version for "apt-get source # pkg=version" that conforms to the current apt pinning. We only # consider binaries which are shipped in all available versions, # otherwise new binaries in pockets would always win. However, if the # same source ships non-overlapping sets of binaries in both pockets, # use the newer ones. """ Would that match the current case? > In general I don't think we can expect the older version of a package > in testing to pass the tests from a newer version in unstable. If the > old version didn't have a feature (for example let's say `hello` in > unstable adds the ability to run `hello --extremely-verbose`), and the > new version has a new test to exercise that feature, I don't see how we > can expect the new test to pass for the old binaries? I think that we don't expect these combinations to always work, it just often enough does, so the code does try it. I mean, there is a reason why the tools say that the other option isn't going to work anyways. I don't expect autopkgtest to take the source from unstable but the binaries from testing. That's a combination I don't recall having seen (in failed tests). The opposite happens very regularly, and often has the same result as a migration-reference/0 run. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature