[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Migration test for glib2.0 unexpectedly using dbusada/unstable source code

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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: