Comment 3 for bug 1902830

Actually one can debug a bit via:
$ export APT_CLONE_DEBUG_RESOLVER=1
$ PYTONPATH=.. python3.8 test_clone_upgrade.py

The libsrt1-gnutls that shows up as proper value in the kubuntu-desktop is mentioned then as:
  Installing libsrt1-gnutls:amd64 as Depends of libavformat58:amd64
But it is listed the same way when handling xubuntu-desktop and missing there.

 libsrt1-gnutls | 1.4.1-5build1 | groovy/universe | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 libsrt1-gnutls | 1.4.2-1 | hirsute/universe | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

So it listed a package that is upgraded.
When doing the initial grab of installed packages it logged
libsrt1-gnutls 1.4.1-5build1 1

The test does
1. create an env of the -2 release (groovy in this case)
   old = self._create_fake_upgradable_root(supported[-2], meta=meta)
2. stores a package selection list of OLD in tarball
3. create an env of the -1 release (hirsute in this case)
   new = self._create_fake_upgradable_root(supported[-1], meta=meta)
4. creates an apt-cache of the NEW env
   cache = apt.Cache(rootdir=new)
5. restores package selection of the "clone of NEW" to the state of "OLD" from tarball

It expects that there are upgrades available under the meta packages of ubuntu-standard""ubuntu-desktop" "kubuntu-desktop" and "xubuntu-desktop". But in the beginning of a release (or at any later time if there are apt network issues) there are none.

I've found that we can make this much more reliable (especially early on when -dev ~= -dev-1 by comparing it with the first release that distro info reports.

With that I have found a fix that eliminates the false positive.
=> https://code.launchpad.net/~paelzer/apt-clone/apt-clone-fix-fails-early-cycle/+merge/393310

This would still be a new upload, so we could accept the badtest now as-is and upload a fixed version later ... up to you (release team people).

@mvo are you still reviewing/merging/uploading those MPs to apt-clone?