Bug#1120361: transition: gdal
On 11/13/25 12:31 PM, Paul Gevers wrote:
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?
You obviously wait, you can't run the tests with the rebuilt dependencies until those are installable.
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?
Maximum wait time is the urgency of the package starting the transition.
If (lib)gdal-grass is a special case that doesn't warrant working making autopkgtest scheduling transition aware, you can just trust the maintainer when he asked you to schedule the relevant packages together without second guessing the maintainer every time.
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).
First time you don't suggest dropping the autopkgtest is counter productive. We're making progress.
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.
That gdal-aware Provides would be specifically for gdal-grass, so not worth the effort.
gdal-grass exists as a separate package to break the circular dependency between gdal and grass.
GRASS uses GDAL to deal with geospatial data, and users of GDAL want to use it to deal with GRASS geospatial data.
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.
It shouldn't need to, we know that you need all the packages involved in the transition.
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?
It can make the reasonable assumption that when a package in testing depends on library package that is no longer built by the version in unstable, that it doesn't make sense to run the autopkgtest of that package in testing with newer dependency from unstable.
There are already cases where britney schedules the tests with the new version of the package being tested from unstable, but that only seems to happen when there is a new version of the source package, not for binNMUs.
It needs to do this for binNMUs as well, and follow the dependency chain to get all of those packages from unstable as well.
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 a
valid way. There's no relation in the archive saying that this isn't going towork.Paul
But libgdal37 is not what's being pulled from unstable.
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: