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
