Hello,

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

Kind regards,
Laurent Bigonville

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:

do not allow to disambiguate the source of the installed package.
The fields that count are [1]:

  Installed-Size
  Depends
  Pre-Depends
  Conflicts
  Breaks
  Replaces

I tried testing src:gzip from trixie and it worked fine, the
"disambiguating field" being:

+Installed-Size: 246
-Installed-Size: 250

Now, if we can think of a good way to disambiguate any of those
fields before the autopkgtest build, we have a fix for this bug.

Just to verify this is sound, I added a

Conflicts: autopkgtest-disambiguate

to bin:libselinux1 in my local source tree, and this resolved the issue.

Cheers,

Paride

[1] https://salsa.debian.org/apt-team/apt/-/blob/bc1fbd12789bfebf225be7af5052840a6add21e2/apt-pkg/deb/deblistparser.cc#L336

Hi,

I've removed the version, as this doesn't look like a regression. (The
version in combination with the bug severity is blocking the migration
to testing).

And we can debate about this. This bug is not about a policy violation,
or makes the package unsuitable for release IMHO. This is a corner case
that hasn't surfaced in all those years. It's a bug and the failure mode
is not transparent.

Paul

Tentative patch:

https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/476

Control: severity -1 important

I agree that this is an important but non-RC bug.

    smcv

Does this proposal work to solve the problem, without applying artificial
modifications to the built package as in the MR that you ended up
proposing?

I observe that in newer Debian installations and container images,
/etc/apt/sources.list is not present, and the OS's own apt sources are
in deb822 format in /etc/apt/sources.list.d/${DEB_VENDOR}.sources.
autopkgtest-build-* and setup-testbed do not set up this situation (yet),
and indeed they might revert it, but other pieces of infrastructure do.

So I think it might be a more realistic reflection of a real Debian system
if we wrote the `deb [ trusted=yes ] file://%(d)s /` apt source that is
used to supply the just-built packages into a very "early" filename
(perhaps 00-autopkgtest.list instead of the current autopkgtest.list),
and renamed /etc/apt/sources.list (if it exists) to something like
/etc/apt/sources.list/autopkgtest-os-default.list?

    smcv

The problem can be fixed by careful ordering of the apt sources, yes.

The ugly thing of this solution is that apt is still unable to
distinguish the packages and gets confused, but in the way that works
well for our purposes. As noted in the MR [1], I now think this is still
better than mangling the source package (what the MR does).

I agree; this is basically the same of what I outlined in [1].

For bookkeeping, the tip of development on fixing this is:

https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/498