On 2024-11-04 13:15, Laurent Bigonville wrote:
> With the unshare backend(?) it seems that rebuilding a package without
> changing the version is causing test to fail becuase it consider the
> same version as a downgrade.
>
> For example:
>
> apt-get source libselinux
> cd libselinux-3.7
> autopkgtest -U -- unshare
>
> The tests fail with something like:
>
> The following NEW packages will be installed:
> libpcre2-16-0 libpcre2-32-0 libpcre2-dev libpcre2-posix3 libpkgconf3
> libselinux1-dev libsepol-dev libsepol2 pkg-config pkgconf pkgconf-bin
> The following packages will be DOWNGRADED:
> libselinux1
> 0 upgraded, 11 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
> E: Packages were downgraded and -y was used without --allow-downgrades.
> E: Failed to process build dependencies
> build FAIL badpkg
Very interesting bug that brought me deep into some apt internals.
This is not virt-server specific.
When the problem you describe happens we have a version table like this:
libselinux1:
Installed: 3.7-3
Candidate: 3.7-3
Version table:
*** 3.7-3 500
500 http://deb.debian.org/debian trixie/main amd64 Packages
100 /var/lib/dpkg/status
3.7-3 1002
1002 file:/tmp/autopkgtest.MYagqq/binaries Packages
When built binaries are made available to the testbed, autopkgtest does
a `apt-get install --reinstall` for those that are already installed, to
enforce usage of the locally built ones. For some reason this is seen as
a downgrade (despite the identical version), but this is fine, as this
operation is done with APT::Get::force-yes=true (see adt_binaries.py).
*However*, if you check the policy table at this point, it will
identical to the previous one. APT has no way to determine the real
source of an installed package: it only knows about _versions_ of
installed packages. [Note how /var/lib/dpkg/status, which contains info
on the installed packages, has no SHA256 for packages.]
Not knowing better, APT assumes that that an installed package comes
from the *first* APT source that provides that version. In our case, it
assumes that libselinux1 3.7-3 comes from deb.debian.org; this is
visible because the "status" source and deb.debian.org are together in
the version table.
This means: APT still thinks the Priority: 1002 package is different
from the installed one, and that we should install (downgrade to) it
when installing the test deps. The test deps are not installed with
APT::Get::force-yes=true, and we get to the failure you encountered.
Is this a (recent) regression? I don't think so. APT behavior on
comparing packages changed in version 2.7.3 to fix #931175, but that
happened in August 2023.
Now, on how to fix this. I can think of two possibilities:
1. We install the test deps with APT::Get::force-yes=true. What would
happen is that we get multiple "downgrades" of the package, every time
we try to reinstall/upgrade it.
2. We move /etc/apt/sources.list *last* in the list of sources, e.g. to
/etc/apt/sources.list/zz-sources.list. This is more correct, but should
be done carefully. You can play with with workaround by passing:
--setup-commands="mv /etc/apt/sources.list
/etc/apt/sources.list.d/zz-sources.list"
And we need a test case for this, as it's way too easy to regress.
Open question: why APT considers reinstalling the same version a downgrade?
Thanks Julian (Cc:) for explaining me most of APT things above.
--
Paride
