Package: autopkgtest Version: 5.30 Severity: wishlist X-Debbugs-Cc: raph...@freexian.com
The current way to schedule autopkgtest tests on reverse dependencies prior to testing migration is not really satisfying: - it relies entirely on APT pinning - you don't have any control on the version used While working on autopkgtest's integration in debusine, I tried to improve this by submitting the precise version of the updated package that I want to validate on the command line (together with the .deb of the package providing the autopkgtests). That works well as the packages gets integrated in the local apt repository prepared. However this doesn't work when the updated package has dependencies that can only be solved in the extra repository. The requirement to use --apt-default-release to stick to the base release means that apt will refuse to install the dependencies from any other repository (unless we use --pin-packages to increase their priority). FTR here are the tries we made to reach that conclusion: https://salsa.debian.org/freexian-team/debusine/-/issues/188 I'm looking for a solution where we don't have to do that analysis of the dependency tree to figure out the set of deb that must be selected. It might not be a big issue in the context of britney, but it's definitely a showstopper in many other contexts. Until apt gets improved (which might happen in time for trixie as juliank told me he has plans to work on a better solver for APT), the best solution is likely to make it possible to use an external APT solver in that special case, just like buildd are doing for experimental builds. In https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300/diffs#note_434295 Paul Gevers said he considered the aspcud resolver but he decided against as it's not the default. I agree that it should not be the default but I still think that we should be able to opt-in to that solution for such tests where we want to run a mixed environment and not have to provide the exact combination of packages that have to be taken from the extra repository. This requires to install apt-cudf and aspcud in the image and then use a command line like this (see man apt-cudf): # apt-get --solver aspcud -o APT::Solver::Strict-Pinning=false -o APT::Solver::aspcud::Preferences="-count(solution,APT-Release:~/[an]=$extra,/),-removed,-changed,-new" install $package I used a regex matching APT-Release here to match both codename (n=) and suites/archive (a=) and I anchored with the trailing comma to be sure to match the full name. FTR the APT-Release field looks like this in the EDSP data structure: APT-Release: v=12.2,o=Debian,a=stable,n=bookworm,l=Debian,c=main,b=amd64 or APT-Release: o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64 If we have multiple extra repositories, we will likely want to have $extra be a regex like "(codename1|codename2)". Note that this is not tested and just based on my personal research so far. For reference, the buildd are using the following criteria for solving build deps of experimental packages: https://salsa.debian.org/dsa-team/mirror/dsa-puppet/-/blob/production/modules/buildd/templates/sbuild.conf.erb $aspcud_criteria = '-count(solution,APT-Release:=/experimental/),-removed,-changed,-new'; Thanks for considering! -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autopkgtest depends on: ii apt-utils 2.7.6 ii libdpkg-perl 1.22.0 ii mawk 1.3.4.20230808-1 ii procps 2:4.0.4-2 ii python3 3.11.4-5+b1 ii python3-debian 0.1.49 Versions of packages autopkgtest recommends: ii autodep8 0.28 ii fakeroot 1.32.1-1 Versions of packages autopkgtest suggests: pn docker.io <none> pn fakemachine <none> pn lxc <none> pn lxd <none> ii ovmf 2023.05-2 pn ovmf-ia32 <none> ii podman 4.6.2+ds1-4 ii python3-distro-info 1.5 ii qemu-efi-aarch64 2023.05-2 ii qemu-efi-arm 2023.05-2 ii qemu-system 1:8.1.2+ds-1 ii qemu-utils 1:8.1.2+ds-1 ii schroot 1.6.13-3+b2 ii util-linux 2.39.2-4 ii vmdb2 0.27+really.0.26-1 ii zerofree 1.1.1-1 -- no debconf information
