[gdal-dev] About bug fix / patch release policy for older GDAL versions (setuptools >= 58.0 and GDAL <3.3 compatibility issues)

Even Rouault even.rouault at spatialys.com
Fri Mar 25 04:07:03 PDT 2022


Snehal,

what you discuss here is all about the patch & backport policy of the 
Debian GDAL package. You can try to file a bug to Debian and point to 
the patch you'd want to see backported, but I can't promise if there 
would be interest in their maintenance team to create an updated package 
with it (my understanding is that even if we'd release a new 3.2.x patch 
release, it wouldn't be packaged in LTS distributions. I'm not sure how 
much of that is linked to Debian policy or availability of people that 
do the work)

For Ubuntu, there's the ubuntugis-unstable PPA with more recent versions.

Using Conda can also be a convenient way to get the latest GDAL on LTS 
releases that stick with older versions: 
https://gdal.org/download.html#conda

Even


Le 25/03/2022 à 07:23, snehal waychal a écrit :
> Dear GDAL Team,
>
> I would like to ask about the patch release policy for the older GDAL 
> versions. I understand that the GitHub issue is not the place to ask 
> such questions and hence posting it here. As this is my first post 
> here, please let me know if I should ask this somewhere else.
>
> On platforms like Debian Bullseye or Ubuntu Focal (current LTS), the 
> GDAL versions available are 3.2.2 and 3.0.4 respectively. Python 
> bindings installation for such older releases (<3.3) works as long as 
> the setuptools version is < 58.0.0. This is due to removal of use_2to3 
> from newer setuptools[1]. This compatibility issue was fixed in GDAL 
> v3.3 release[2]. There is a system package python3-gdal but if I 
> understand correctly this is available for the default python version. 
> So this doesn't work for official python docker images based on Debian 
> LTS where the python version is different from system one.
>
> As LTS platforms mentioned above with older GDAL versions are widely 
> used and there are situations where newer setuptools usage is enforced 
> (e.g. by modern python package manager tools, see issues in pipenv[3] 
> or poetry[4]), we face quite some trouble to have GDAL python package 
> working in complex python environments. Considering the discussion in 
> linked issues, this also affects GDAL users as well [5].
>
> We could use some inconvenient workarounds but it would be helpful if 
> there could be a patch release for issues like setuptools 
> compatibility in older GDAL versions (e.g. 3.2.2) which are commonly 
> used on LTS platforms like Debian Bullseye. And especially when the 
> effort of backporting fix like [1] is simple as patch[2] is directly 
> applicable:
>
> ```console
> git clone https://github.com/OSGeo/gdal.git -b v3.2.2
> git cherry-pick 36b6ccdb0e6889743c2ec8b9d8cd7fee3d2df9dd 
> --strategy-option theirs
>
> # minor some changes and generate sdist for pypi release
> python setup.py sdist
> ```
>
> Given the above considerations, I wonder if there would be a 
> possibility of having patch releases. I think creating PR won't be 
> much work if this would be an acceptable policy. I believe this would 
> help quite some people.
>
> Thank you!
>
> [1] https://github.com/OSGeo/gdal/issues/4467
> [2] 
> https://github.com/OSGeo/gdal/commit/36b6ccdb0e6889743c2ec8b9d8cd7fee3d2df9dd
> [3] https://github.com/pypa/pipenv/issues/2364
> [4] https://github.com/python-poetry/poetry/issues/1584
> [5] https://github.com/pypa/setuptools/issues/2781
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.



More information about the gdal-dev mailing list