Hi, On 11/13/25 11:01, Sebastiaan Couwenberg wrote:
When scheduling tests for rdeps of a package that got updated in unstable, check if that package has an ongoing transition.
That's what I meant with out-of-the-archive information later on. britney2 currently doesn't have the information about which transitions are ongoing. But indeed, we could fix that, after all the transition tracker lives on the same host and we're pulling data from external source already anyways.
Check the test dependencies of the rdep the tests are getting scheduled for against the list of binary packages that are getting a new build in unstable as part of the transition, and ensure those packages get pulled from unstable instead of testing as we want the packages that got rebuilt during the transition.
And what to do when the binaries haven't been rebuilt yet? Wait? If so, until when? If we wait until the rebuild happens than we loose the smooth updates feature. If not waiting, should be schedule like now? In the latter case I fear we would only gain something in a minority of cases. Maybe we could let the behavior depend on the size of the transition?
If these packages need to use the same version of libgdal, shouldn't there be a package relation between these packages that ensures that (at build time)?Are you suggesting we do source-full uploads of (lib)gdal-grass every time gdal is updated to use strict versioned build dependencies which trickle down to the binary dependencies?
No, I meant a binNMU that happens as part of the transition would fix the dependencies.
I don't think that works for test dependencies which don't get the same treatment as binary packages built from that source.
I wasn't really specifically considering test dependencies here. I was considering regular binary package relations.
Dropping the autopkgtest is so much less work.
Sure, having autopkgtest isn't required (nor would such a requirement make sense).
In unstable where the (lib)gdal-grass and its dependencies get rebuilt as part of the transition, they have the appropriate gdal dependency.Package: libgdal-grass Version: 1:1.0.4-2+b1 Depends: grass841, [...], libgdal38 (>= 3.12.0), [...] Package: grass-core Version: 8.4.1-1+b2 Provides: grass841
Not implying it's worth the effort (and maybe it would be dumb for other reasons), but this Provides *could* encapsulate the SONAME of libgdal that it got compiled against and then the libgdal-grass rebuild could lock into that. At least it would ensure the lock-step migration of both and would ensure that britney2 schedules the tests as you intended and would ensure that users install a set that works together.
Depends: [...], libgdal38 (>= 3.0.0), [...] Using grass from testing which doesn't use the new gdal does not work.
But currently the package relations don't reflect that.
Why does it think this is going to work?
Because the package relations don't tell it that it's not going to work. How should it know?
The libgdal-grass test dependencies include: gdal-bin (built from src:gdal) libgdal-grass (built from src:libgdal-grass)The libgdal-grass binary package in testing depends on libgdal37 (>= 3.11.0) which is not provided by gdal from unstable, the same goes for grass-core in testing which depends on libgdal37 (>= 3.11.0).
Sure, but libgdal37 is available and satisfies the package relations in avalid way. There's no relation in the archive saying that this isn't going towork.Paul
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature