On 2026-01-26 10:22, Jochen Sprickerhof wrote: > * [email protected] <[email protected]> [2026-01-26 00:29]: >>For ratt/Salsa CI rdep jobs I chose --build-dep-resolver=aspcud >>specifically to mimic buildd behaviour as closely as possible. It looks >>like buildds also use aspcud (at least for the experimental), for > > More specifically _only_ for experimental. (Afaik that is only configured in > the wanne-build DB but is visible in the buildd logs.) > >>Given you're working on dropping aspcud/aptitude usage in Debian in >>favour of apt (with the proposed relaxed pinning behaviour), does it >>make sense for us to remove aspcud now from the Salsa CI rdep jobs and >>switch to the default apt resolver already? Or would you recommend >>keeping aspcud until buildds have switched, to stay aligned with current >>buildd semantics? > > That depends on what salsa-ci does. aspcud is used to get build dependencies > from experimental when building _against_ experimental. That is probably > rather the exceptional case.
Just to clarify, in the salsa-ci rdep job we only enable aspcud + the buildd like criteria when the target build is for experimental (that is, when building against experimental). For the normal case we use the default apt resolver, so this is indeed the exceptional path. > Btw. I would also question the use of ratt as it is not used in Debian in > general and last time I checked a three line shell script would do a better > job. Do you have any reason to use it? Regarding ratt, we use it mainly because it generates the full sbuild command lines for rebuilding reverse build-dependencies, and it wraps dose-ceve so the reverse build-dep closure is computed correctly (architecture context, filtering, etc) If there is a preferred Debian approach, I'd appreciate a pointer and I can check whether it fits the salsa-ci rdep job. > > Cheers Jochen Cheers, Aquila Macedo
