sbuild: Pin experimental extras with --add-depends

[aquilamacedo]

This MR tweaks how ratt handles .changes that target experimental.

By default, even if the input .changes is for experimental, ratt resolves and rebuilds reverse build-deps from unstable, and only injects the locally built .debs from that .changes via sbuild --extra-package. That is the workflow most people want when doing rdep testing.

In case a user wants buildd-like experimental behavior, they can pass -sbuild-experimental-aspcud. In that mode, sbuild enables the experimental overlay and uses the buildd aspcud criteria:

-count(down),-count(changed,APT-Release:=/experimental/),-removed,-changed,-new

One gotcha with those criteria is that aspcud can still pick dependencies from unstable even when --extra-package is provided. That can make rdep builds use the in-archive versions instead of the .deb you are testing, which can hide regressions (see https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/519). To avoid that, when experimental+aspcud mode is enabled and extra .debs are provided, we also add each of them as an exact build-dependency via --add-depends='pkg (= version)', forcing the solver to install the intended versions.

[aquilamacedo]

I also considered other options (like tweaking the aspcud criteria or using apt
pinning), but TBH this seemed like the most practical solution that stays
self contained in ratt/sbuild.

The main downside is that the sbuild command line grows with the number of
extra binaries, since each one becomes an --add-depends entry. I don't expect
this to be a big problem in practice, but if you or @ottok or @stapelberg
see a cleaner way to ensure the extra experimental .deb files are always used,
I'm happy to rework it.

It would be useful if sbuild had a native option to install specific .deb files
directly in the chroot without running them through the dependency solver. That
would help avoid overly long sbuild command lines when a source package
produces many binary .deb files.

[rbalint]

@aquilamacedo IMO this will break builds when the produced binary packages are in conflict. I think the best way would be going with pinning.
Also simply adding dependencies could make the tested reverse dependency packages build in unexpected ways.

[aquilamacedo]

@aquilamacedo IMO this will break builds when the produced binary packages are in conflict. I think the best way would be going with pinning.
Also simply adding dependencies could make the tested reverse dependency packages build in unexpected ways.

Thanks for the suggestion. After discussing this with the sbuild maintainer, pinning did not look like a viable solution because the aspcud resolver does not consistently honor APT pinning, so it would not guarantee the injected experimental .deb's get installed instead of falling back to in-archive packages from unstable.

[aquilamacedo]

Hi @stapelberg, I just updated this PR with some new changes. Could you please take another look and merge it if everything looks good?