Bug 2417148
| Summary: | GDAL Removal Caused Missing Functionality | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | 5mhjx1clu |
| Component: | gdal | Assignee: | markusN <neteler> |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | epel9 | CC: | alex, cjw, devrim, jjasen, manisandro, neteler, nmielcarek, pavel.lisy, praiskup |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
5mhjx1clu
2025-11-25 21:10:12 UTC
Seeing the same issues here which has caused us to revert back to 3.4.3. However, since the primary gdal package was moved from EPEL to RHEL appstream, this perhaps should be posted in that group instead.
Similar example when looking for geotiff support:
gdal-3.4.3-3.el9.x86_64
$ ldd `which gdalinfo` | grep geotiff
libgeotiff.so.5 => /lib64/libgeotiff.so.5 (0x00007fb7879ca000)
gdal-3.10.3-3.el9.x86_64
$ ldd `which gdalinfo` | grep geotiff
(empty)
In fact, 3.10.3 is only linked with 53 libs while 3.4.3 has 103.
Same issue. Reproduce: wget -nv https://mrms.ncep.noaa.gov/data/RIDGEII/L2/CONUS/CREF_QCD//CONUS_L2_CREF_QCD_20251207_144436.tif.gz -O CONUS_L2_CREF_QCD_20251207_144436.tif.gz gunzip CONUS_L2_CREF_QCD_20251207_144436.tif.gz gdalwarp CONUS_L2_CREF_QCD_20251207_144436.tif tmp_radar.tiff ERROR 4: `CONUS_L2_CREF_QCD_20251207_144436.tif' not recognized as being in a supported file format. ERROR 4: Failed to open source file CONUS_L2_CREF_QCD_20251207_144436.tif There is more activity about issue this on the RedHat forums: https://issues.redhat.com/browse/RHEL-107107 https://issues.redhat.com/browse/RHEL-134116 https://issues.redhat.com/browse/RHEL-134206 Here is the resulting comment in case you don't have redhat accounts: "Thank you for your report, but unfortunately, I have to state that CMake isn't misconfigured; it's configured properly. I understand that some drivers are missing in the CS/RHEL repositories, but they were not intended to be added. We have prepared a gdal-epel package that should provide more drivers. Please try it and let me know if it helps." I'm stuck on finding this new gdal-epel package. Maybe my repo mirrors haven't synced up yet, but when I run "dnf search gdal-epel" I don't see any results yet. This whole gdal switchover has been poorly planned. https://packages.fedoraproject.org/pkgs/gdal-epel/ I too cannot find 'gdal-epel' as its own package, but I do see its subpackages: $ sudo dnf list --available gdal* | grep epel gdal-java.x86_64 3.10.3-7.el9 epel gdal-javadoc.noarch 3.10.3-7.el9 epel gdal-python-tools.x86_64 3.10.3-7.el9 epel There is a new unofficial repo that tries to restore driver support. I am able to install it with no problem on CentOS Stream 9 alongside appstream's minimized gdal, but I encounter runtime errors that I have not been able to reproduce on my own source builds of gdal. https://copr.fedorainfracloud.org/coprs/pkhartsk/gdal-extras/ FWIW PostgreSQL RPM repository provides support for way many more drivers and it is always up2date: https://yum.postgresql.org/ Adding another repository isn't a good fix in my opinion, especially since other programs in EPEL already rely on gdal such as QGIS. We have also encountered problems with this change, as now components relying on GDAL cannot parse GeoTIFF or TIFF files. |