Hi,

yesterday I spent an afternoon debugging a failing CI tests on ansible-core, and
noticed that it is caused by this setting in
/etc/apt/preferences.d/90autopkgtest:

Package: *
Pin: origin ""
Pin-Priority: 1002

The ansible CI test in question creates a local apt repository with several
package versions, and then tests installation/upgrade paths using the ansible
apt module (which internally uses python3-apt). When this pinning is set, the
local apt repo is affected by the pin, and every versioned installation will
fail with e.g. "Task failed: Module failed: no available installation candidate
for foo=1.0.0". The reproducer is described here:
https://github.com/ansible/ansible/issues/85147

My workaround is to delete the file before running the tests.

While I believe it's a bug in python3-apt or ansible-core, I think we should be
more cautious about setting the pin priority, as this might also affect other
software doing similar tests. AFAICS this pinning shouldn't be needed, as the
package being tested should always have a higher version number than the one in
the apt archive.

So my questions are: Is this really needed? And if yes, could we instead do a
narrower apt pinning at runtime to the specific packages in question?

Greets,
Lee

Hi Lee,

Over the years, we've tried multiple things to improve how we're
ensuring that the right packages are tested. We have ideas how to
further improve things, but it's extremely hard to do, because there are
so many things to consider. See e.g. bug #1052119 as an example where we
had to revert an improvement related to pinning, because it didn't play
nicely (yet).

Paul

As Paul mentioned, the logic around the pinning that autopkgtest sets is
complex and delicate. At first glance "the package being tested should
always have a higher version number", but in practice there are many
other things to consider.

Specifically, the pin you found problematic ensures that the locally
built version of a package is the one that will be tested. This allows
users to work on autopkgtests for a package without bumping the package
version. See also:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086701
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/498/

Cheers,

Paride