Is anyone using posit package manager serving red hat binaries? How are you dealing with the issue that red hat has two versions of gdal? https://developers.redhat.com/articles/2026/02/27/gdal-34-package-full-featured-gis-functionality-rhel
This affects binaries of packages such as terra.
Hey @novica, from the Posit Package Manager side, we won't be changing anything for now as RHEL has added GDAL 3.4 as a parallel install that doesn't conflict with the original GDAL. So you can have both installed, and binary packages that use GDAL should still work as before.
A switch to GDAL 3.4 might be possible in the future, but it's 100% going to break anyone already using sf or other GDAL-using packages when the new binary suddenly starts depending on a brand new system dependency. So we'd prefer not to do that within RHEL 9, unless sf or other packages absolutely need the newer GDAL 3.4.
The fact that the GDAL 3.4 binary names are all different also complicates the migration, as it's possible that you can't just install gdal3.4 and have everything work. But as the article says, users may also have to create all those symlinks manually for GDAL-using software to work.
Hi @greg. Thanks for your reply. The issue I had was that the binaries were still trying to run with the system GDAL (not GDAL 3.4) and then I had to build packages from source. It is not a big obstacle, but I was curious how other have approached this.
Oh gotcha. In that, that's exactly what I would recommend, to build your GDAL 3.4 using packages from source and not use the Package Manager binaries.
But, since rhel is a supported distribution, shouldn't the binaries for it be compiled against gdal 3.4? Or am I misunderstanding something?
Changing the binaries to compile against the new GDAL 3.4 instead of the default GDAL will be a breaking change for anyone already using the PPM binaries, because it'll introduce a new runtime system dependency on GDAL 3.4.
For example, someone might be using the sf 1.1-0 binary on RHEL 9 just fine today. If we build the next version of sf with GDAL 3.4, or rebuild 1.1-0 with GDAL 3.4, it's likely their next installation of sf will fail to load with an error like libgdal.so.30: cannot open shared object file. Of course it can be addressed by installing gdal3.4-libs, but it's still a disruptive change we'd prefer not to make within a distribution unless absolutely necessary.
Another issue could be that the default GDAL shipped in RHEL/EPEL 9 is GDAL 3.10. This new GDAL 3.4 package is actually an older GDAL by several years. Could there be unintended consequences and breaking changes with suddenly downgrading the GDAL version? I'm not sure, but it's also another reason to play it safe here.
Many thanks for your answer.
The issue with well at least terra that i was looking to use is that the default gdal is missing a lot of formats, so the package is kind of useless for many operations that it would be typically used.
And this is indeed a breaking change because prior to updating to 3.10 gdal actually had support for the formats and the upgrade on RH side broke the usual behavior of the package binaries.