Re: Migration test for glib2.0 unexpectedly using dbusada/unstable source code
On Fri, 28 Feb 2020 at 20:18:21 +0100, Paul Gevers wrote:
> """
> # 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?
Yes, good catch. dbusada is in this situation:
- old (tests pass): dbusada_0.4.2-3 builds libdbusada4-dev, libdbusada0.4.1
- new (uninstallable, and indeed unbuildable): dbusada_0.5.0-3 builds
libdbusada5-dev, libdbusada0.5.0
It seems a bit of a stretch to say this is a regression "caused by" the
proposed glib2.0 migration.
Would it perhaps be feasible to have autopkgtest report that it is in the
"no overlap" case, and make debci or the testing machinery treat a failure
as not a regression? Or treat "I can't install the test dependencies"
as not a regression? Or something?
(Or perhaps choose the source from testing if the disjoint set of
binaries that the source in unstable claims to build are missing from
the Packages file? Although hopefully this is too rare for that to be
worth it, if maintainers are testing their uploads in an appropriate
build chroot/container like they should.)
> I think that we don't expect these combinations to always work, it just
> often enough does, so the code does try it.
That's fine, up until the point where it gets flagged as a regression that
blocks a not-closely-related package.
> 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).
If the unstable source is only chosen in the case where it ships a
set of binaries that does not overlap the set built in testing, then
I don't think this can happen (except perhaps in rare cases with some
pathological Provides). So that resolves my concern about what happens
when a new test exercises a new feature.
> The opposite [tests from source from testing running against binaries
> from unstable] happens very regularly, and often has the same result
> as a migration-reference/0 run.
That's conceptually somewhat safer because packages aren't usually meant
to remove features, so the old tests will usually still pass in the new
package (although it could still break in cases where the old tests make
"non-API" assumptions about the code under test, and those assumptions
become false in the new binaries).
smcv
Reply to: