#737 closed defect (fixed)
Patch needed for GDAL 3.4.2
Reported by: | andreaerdna | Owned by: | |
---|---|---|---|
Priority: | major | Component: | Package |
Version: | Keywords: | ||
Cc: |
Description (last modified by )
After the update of the gdal
package in OSGeo4W to version 3.4.2 in order to enable the fix provided by PR QGIS/qgis#47098 for the issue QGIS/qgis#23991, some issues caused by the same PR QGIS/qgis#47098 have been discovered:
1) QGIS/qgis#48003 "Geopackage from network location is not a valid or recognized data source"
2) QGIS/qgis#48154 "Adding additional layers to GPKG does not load them correctly"
3) QGIS/qgis#48024 "Cannot add GeoPackage layer with hash symbol # in file path"
These issues affects current QGIS 3.25.0-Master and QGIS 3.24.1 (qgis 3.24.1-2) when built against GDAL 3.4.2 (qgis 3.24.1-1 is not affected). They doesn't affect QGIS LTR 3.22.5, since the offending PR QGIS/qgis#47098 has been backported to 3.22.6.
While the issues 1) and 2) have been fixed (the first one with qgis#48059 and QGIS/qgis#48119 and the second one with QGIS/qgis#48157) with patches in QGIS (backports for 3.22 and 3.24 branches are awaiting merging, which will hopefully happen before the release of the forthcoming QGIS versions), the issue 3) has been fixed with a patch in GDAL (both in master OSGeo/gdal#5554 and 3.4 OSGeo/gdal#5571 branches).
So, since a GDAL 3.4.3 release that contains the patch for the issue 3) is not yet available, I propose to temporary apply the GDAL patch OSGeo/gdal#5571 in the OSGeo4W gdal
package to prevent that the issue 3) will affect the forthcoming QGIS 3.24.2 and QGIS LTR 3.22.6.
Change History (3)
comment:1 by , 3 years ago
Description: | modified (diff) |
---|
comment:2 by , 3 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
GDAL 3.4.3 has been released.
GDAL 3.4.3 contains the patch OSGeo/gdal#5571, so when the gdal package will be updated to 3.4.3 then it shouldn't needed anymore to apply the patch https://github.com/jef-n/OSGeo4W/commit/4e7e882467d8fc9ae732e5e894c1e6e0ef7848d9 in OSGeo4W.