General advice | repo 'dependency issues

Support
1

One of the (many) perks of AlmaLinux is that I don’t frequently descend into ‘dependency hell’. But, with today’s update from 9.6 → 9.7, I have such a situation involving: gdal, and proj. They may or may not be ‘related’, but, I’ll discuss gdal alone as an example:

 dnf list gdal*

yields

Last metadata expiration check: 0:03:59 ago on Mon 17 Nov 2025 04:06:04 PM EST.
Installed Packages
gdal.x86_64                              3.4.3-3.el9                   @epel
gdal-devel.x86_64                        3.4.3-3.el9                   @epel
gdal-doc.noarch                          3.4.3-3.el9                   @System
gdal-java.x86_64                         3.4.3-3.el9                   @epel
gdal-libs.x86_64                         3.4.3-3.el9                   @epel
gdal-perl.x86_64                         3.4.3-3.el9                   @epel
Available Packages
gdal.x86_64                              3.10.3-3.el9                  appstream
gdal-devel.i686                          3.10.3-3.el9                  crb
gdal-devel.x86_64                        3.10.3-3.el9                  crb
gdal-javadoc.noarch                      3.4.3-3.el9                   epel
gdal-libs.i686                           3.10.3-3.el9                  appstream
gdal-libs.x86_64                         3.10.3-3.el9                  appstream
gdal-python-tools.x86_64                 3.4.3-3.el9                   epel

If I try to upgrade gdal, lots of errors like:

 Error:
 Problem 1: package gdal-perl-3.4.3-3.el9.x86_64 from @System requires libgdal.so.30()(64bit), but none of the providers can be installed
  - package gdal-perl-3.4.3-3.el9.x86_64 from @System requires gdal-libs(x86-64) = 3.4.3-3.el9, but none of the providers can be installed
  - cannot install both gdal-libs-3.10.3-3.el9.x86_64 from appstream and gdal-libs-3.4.3-3.el9.x86_64 from @System
  - cannot install both gdal-libs-3.4.3-3.el9.x86_64 from epel and gdal-libs-3.10.3-3.el9.x86_64 from appstream
  - cannot install the best update candidate for package gdal-perl-3.4.3-3.el9.x86_64
  - cannot install the best update candidate for package gdal-libs-3.4.3-3.el9.x86_64

So, is this just a matter of ‘waiting until epel catches up’, or is there something I could (and should) do in the interim?

Again, this sort of thing is something I rarely run into on my AlmaLinux machines.

2

Hello,
It looks like EPEL is just waiting to add support for gdal-libs-3.10.3-3.el9.
Thank you.

3

Yes.

You have EPEL package (gdal-perl) that requires specific version of other package (gdal) that does already have different version available. Therefore, they have to upgrade them simultaneously.

For now, you can exclude packages from update. For example:

dnf up --exclude=gdal\*

Alternatively, if the packages from EPEL (e.g. gdal-perl) are not essential, then you could remove them (for now).

Looking more carefully, the gdal is not that trivial. Note how practically all of gdal 3.4 is from EPEL?
An EPEL policy is to not offer what base distro does already offer. Therefore, if el9 has gdal, then EPEL should not have it. The plot thickens. el9_6 did not have any of gdal, but el9_7 does.

Presumably RHEL 9.7 did include gdal (3.10) as new package.

Indeed: 2376349 – Notice: gdal will be automatically retired from EPEL 9 when RHEL 9.7 is released
That page has some advice.

4

Many thanks. Pointing out the deprecation on EPEL, and move to RHEL clarified strategy (thanks!), which worked. Simply erased installed gdal (and proj, which interacts with it), and re-installed new versions from RHEL.

1 Like
5

from AlmaLinux. :slightly_smiling_face:

6

Whoops! :face_with_peeking_eye: Thanks for reminding me.

7

Hi,

after recent update from 9.6 to 9.7 i have observed two minor mismatch:

  • Updates complementary with qt6 and many others package that require “sudo dnf update --allowerasing” to operate correctly
  • Now when i try to use hibernate , system d’ont stop shutdown electricaly. I want to stop with switch on/offI
  • I tested to modify parameters in /etc/systemd/logind.conf and other file without success !

Regards

HI