Hi, 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. 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 libgdal37Notice grass-core missing from that list. See also README.source:https://sources.debian.org/src/libgdal-grass/1%3A1.0.4-2/debian/ README.sourceRunning 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)? 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.
Paul
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature