Bug#1120361: transition: gdal
On 11/13/25 10:24 AM, Paul Gevers wrote:
On 11/13/25 09:27, Sebastiaan Couwenberg wrote:
So depressing we have this discussion every gdal transition, see prior transitions:
I recognize what you say here, after you linked the bugs. Maybe next time just remind us of earlier discussions and don't rely on our memory.
I really should just drop the autopkgtest as it's just a hindrance to testing migration as long as britney is doesn't know it should get all dependencies from unstable when testing packages involved in a transition.
Can you please elaborate on what exactly you think britney should do.
When scheduling tests for rdeps of a package that got updated in unstable, check if that package has an ongoing transition.
If there is no ongoing transition, just pull the package that got updated from unstable.
If there _is_ an ongoing transition for that package, get a list of source packages involved in that transition, expand this list to the arch:any packages built from those source packages.
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.
In most case you'll likely get the same behavior as now, where only the binary packages built from the gdal source get pulled from unstable, but in the case of (lib)gdal-grass it would also pull the binary packages built from the grass package from unstable because it part of the list of binary packages getting rebuilt for the ongoing transition.
Until now I haven't really been able to construct the right logic without dropping the smooth transition concept. While not being perfect, smooth transitions are an important tool for the release managers. I *think* (but I could be wrong) that what you want is conflicting with that. (At least, without having out-of-the-archive information about ongoing transitions).
The following packages come from unstable in the test:
gdal-data
gdal-plugins
libgdal38
python3-gdal
gdal-bin
libgdal37
Notice grass-core missing from that list.
See also README.source:
https://sources.debian.org/src/libgdal-grass/1%3A1.0.4-2/debian/ README.source
Running the autopkgtest with grass from testing pulls in its old libgdal dependency, hence the need to also pull grass from unstable to have both grass & libgdal-grass using the same libgdal.
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?
I don't think that works for test dependencies which don't get the same treatment as binary packages built from that source.
Dropping the autopkgtest is so much less work.
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
Depends: [...], libgdal38 (>= 3.0.0), [...]
Using grass from testing which doesn't use the new gdal does not work.
britney schedules this:
Trigger/Pinned packages
gdal/3.12.0+dfsg-1
src:gdal from unstable
Why does it think this is going to work?
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).
If not, why not? With a relation in place that ensures that, britney would schedule the tests with those pieces from unstable. While partial upgrades are still not officially supported in Debian, we're getting better at them (also because autopkgtest spots issues). Isn't this a somewhat similar case?
I noticed you filed bug 1120377. I've added a testing removal hint so *this* issue should go away soon IIUC.
Once gdal-grass migrates to testing the discussion just moves to there.
Kind Regards,
Bas
--
PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: