Enable the use of alternative resolvers for some tests

Copied from https://lists.debian.org/debian-backports/2021/12/msg00020.html

On 16-12-2021 14:01, Antonio Terceiro wrote:

On Thu, Dec 16, 2021 at 11:00:32AM +0100, Paul Gevers wrote:

==== ISSUES ==== It seems that the setup sometimes has some trouble installing the right packages in the backports setup. I.e. if there's a versioned dependency that has to come from backports too, or a package that's only available in backports (in the nncp autopkgtest) it doesn't install it. I thought apt should just install the package from backports (as implicitly documented by [1]), but I see this: """ root@autopkgtest-lxc-edukey:/# apt-get install python3-azure-cli/bullseye-backports Reading package lists... Done Building dependency tree... Done Reading state information... Done Selected version '2.31.0-2~bpo11+1' (Debian Backports:bullseye-backports [all]) for 'python3-azure-cli' Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation:

The following packages have unmet dependencies: python3-azure-cli : Depends: python3-azure (>= 20211104+git-1~) but 20201208+git-6 is to be installed Recommends: python3-azext-devops but it is not going to be installed E: Unable to correct problems, you have held broken packages. """ I've read apt_preferences(5) multiple times, but I still don't get why it fails. This is supposed to work, right?

Not with the default apt configuration. You would -t bullseye-backports to allow packages from backports to be installed as dependencies, or to install an suitable pinning file raising the priority of bullseye-backports. However in this case we would want to raise the priority only of the packages you really need, not of the entire backports repository.

We should be seeing similar issues on the experimental pseudo excuses, with packages from experimental that depend on other packages from experimental.

So, should we (like the buildds) use the apscud resolver for the experimental and backports pseudo excuses?

I think this needs support in debci, which could inject an apt configuration snippet into the testbed (after making sure the resolver is installed).