I’m trying to run a program that requires gdal. After installing the gdal package in almaLinux 9.7 I noticed that the GTiff format I require is not present. I only have:
$ gdalinfo --formats
Supported Formats: (ro:read-only, rw:read-write, +:update, v:virtual-I/O s:subdatasets)
VRT -raster,multidimensional raster- (rw+v): Virtual Raster (*.vrt)
MEM -raster,multidimensional raster- (rw+): In Memory Raster
On the other hand, a Fedora system has lots of formats, including GTiff
I have installed libtiff and libgeotiff, but nothing changes
$ rpm -q libgeotiff libtiff gdal
libgeotiff-1.7.1-5.el9.x86_64
libtiff-4.4.0-15.el9_7.2.x86_64
gdal-3.10.3-3.el9.x86_64
Hi,
I can reproduce the same behavior on AlmaLinux 9.7 with the AppStream packages:
- Installed: gdal-3.10.3-3.el9, gdal-libs-3.10.3-3.el9
- gdalinfo is /usr/bin/gdalinfo from that RPM
gdalinfo --formats shows only VRT and MEM- /usr/lib64/gdalplugins contains only drivers.ini
So formats like GTiff are missing even though gdal-libs is installed.
As a workaround, I rebuilt an older EL9/EPEL SRPM (gdal-3.4.3-3.el9.src.rpm) with mock and installed the resulting RPMs locally; then GTiff and many other drivers appear.
Example workaround steps:
curl -O ftp://ftp.icm.edu.pl/pbone/archive.fedoraproject.org/epel/9.5-2025-05-13/Everything/source/tree/Packages/g/gdal-3.4.3-3.el9.src.rpm
mock -r /etc/mock/alma+epel-9-x86_64.cfg --rebuild gdal-3.4.3-3.el9.src.rpm
sudo dnf -y localinstall /var/lib/mock//result/gdal-3.4.3-3.el9.x86_64.rpm /var/lib/mock//result/gdal-libs-3.4.3-3.el9.x86_64.rpm --allowerasing
This looks like a packaging/build regression in the AppStream gdal 3.10.3 packages. Where should this be reported (AlmaLinux/RHEL)?
Rebuilding from SRPM with mock works as a workaround, but it’s not a reasonable solution for typical users; the AppStream package should ship working drivers (at least GTiff) out of the box.
Thanks
If you can reproduce it in CentOS Stream 9 (or RHEL 9), then report to Red Hat.
If RHEL gdal has more formats than AlmaLinux, then it is a bug in AlmaLinux.
Thanks. Understood — CentOS Stream bugs are tracked in Red Hat Jira (RHEL project). I’ll file a report in Red Hat Jira for this issue and will post the link here once it’s created.
In the issue you say “I created this issue by mistake due to a misunderstanding”
So is it not a bug? What’s the solution?
Filed: RHEL-136706 (link)
The “created this issue by mistake due to a misunderstanding” wording was about me posting the wrong link (I deleted that post). I still believe this is a real packaging bug
Workaround (works for me on AlmaLinux 9.7):** use an older EL9/EPEL GDAL build (e.g. rebuild gdal-3.4.3-3.el9.src.rpm with mock) and install the resulting gdal/gdal-libs RPMs.
The exact commands are in my earlier post in this thread (the one with the mock rebuild steps).
Tracking in Red Hat Jira: RHEL-136706
Thanks. I don’t think this is a missing dependency. It looks like the AppStream build is shipping without the real drivers. On AlmaLinux 9.7, gdalinfo --formats only shows VRT/MEM. With gdal-libs installed, /usr/lib64/gdalplugins/ has drivers.ini but no actual driver modules, so GTiff (and others) are missing out of the box.
I just experienced the same issue. The fix for me - your mileage may vary, this is a messy box I’m on - was to run a yum downgrade on the relevant packages:
yum downgrade gdal gdal-devel gdal-libs
After that, all formats restored!
What are the versions of those packages after the downgrade?
(I see only one version, 3.10.3-3.el9, in repos.)
Ah, sorry, I missed the detail that this was on 9.7. I’m running AlmaLinux version 10, and while the latest GDAL packages exhibit the same behaviour described here, I don’t know whether a downgrade route exists for 9.*.
For what it’s worth, I’m using x86-64-v2architecture, and I downgraded to 3.el10_0.alma_altarchfrom the epel repo.
The “broken” version missing all the drivers is Version 3.10.3 Release 3.el10, which shows as an available update in the appstream repo.
Interesting:
[Alma 9]# dnf -q --enablerepo=epel list gdal gdal3.4 --showduplicates
Available Packages
gdal.x86_64 3.10.3-3.el9 appstream
gdal3.4.x86_64 3.4.3-5.el9 epel
[Alma 10 v2]# dnf -q --enablerepo=epel list gdal --showduplicates
Available Packages
gdal.x86_64_v2 3.10.0-3.el10_0.alma_altarch epel
gdal.x86_64_v2 3.10.3-3.el10 appstream
EPEL 9 has old gdal with distinct name, so it will never compete with distro version.
EPEL 10 has packet with same name as AppStream. Isn’t it EPEL policy to not do that?
That is obviously not a question for AlmaLinux, except …
I do not see “gdal*” in EPEL 10z x86_64. Therefore, the 3.10.0-3.el10_0.alma_altarch package is only in AlmaLinux’s x86_64_v2 version of EPEL. That is an AlmaLinux “issue”.