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!