# Wrong version of proj in rocky linux 9.7 repos
**URL:** https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040
**Category:** Rocky Linux Help & Support
**Tags:** rocky-linux-9
**Created:** [December 11, 2025, 9:37am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040 "2025-12-11T09:37:43Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@mats](https://forums.rockylinux.org/u/mats)
#### Post date: [December 11, 2025, 9:37am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/1 "2025-12-11T09:37:43Z")
I have been running the rockylinux docker image to install software from this rpm: [Index of /RockyLinux/9/latest](https://rpm.baltrad.eu/RockyLinux/9/latest/), for a couple of months now.
Recently I tried to rebuild this image, but it failed, because it could not find the correct proj version (it needs libproj.so.22; proj version 8.2.0, but installed is libproj.so.25; proj version 9.6.0). I contacted the developers of that RPM already and they say that RedHat 9.7 comes with proj 8.2.0 still in its repos, but in the RockyLinux 9.7 repos it is 9.6.0 everywhere (in the proj-devel package in crb and in the proj package in AppStream).
Looking in the RockyLinux 9.6 vault I cannot find any of these packages in there at all, so I cannot confirm that those repos had the correct version, but an earlier built docker image does have the correct proj version installed using the same install commands. Also I do not have a RedHat licence myself, so I cannot confirm that those repos have the correct version of this package.
Furthermore this issue seems to not only be with the RockyLinux 9.7 version, because any 9.x docker image seems to just install the proj 9.6.0, while it used to be proj 8.2.0 before.
I have been looking through the forums and bug reports and I cannot find any mention of this. Can someone help me out here?
---
### Author:  [@iwalker](https://forums.rockylinux.org/u/iwalker)
#### Post date: [December 11, 2025, 9:47am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/2 "2025-12-11T09:47:46Z")
Rocky comes with the same packages as RHEL, as seen below:
```auto
root@rhel9:~# dnf list proj --showduplicates
Updating Subscription Management repositories.
Last metadata expiration check: 0:00:21 ago on Thu 11 Dec 2025 10:38:43 AM CET.
Available Packages
proj.i686 9.6.0-2.el9 rhel-9-for-x86_64-appstream-rpms
proj.x86_64 9.6.0-2.el9 rhel-9-for-x86_64-appstream-rpms
```
that is the same version that is in Rocky9. Now, let’s take a look inside that rpm:
```auto
root@rhel9:~# dnf repoquery -l proj
Updating Subscription Management repositories.
Last metadata expiration check: 0:00:44 ago on Thu 11 Dec 2025 10:38:43 AM CET.
/usr/bin/cct
/usr/bin/cs2cs
/usr/bin/geod
/usr/bin/gie
/usr/bin/invgeod
/usr/bin/invproj
/usr/bin/proj
/usr/bin/projinfo
/usr/bin/projsync
/usr/lib/.build-id
/usr/lib/.build-id/0c
/usr/lib/.build-id/0c/54b1669fd22823f7f254af878cf8bf42a549a4
/usr/lib/.build-id/17
/usr/lib/.build-id/17/443150ea8f0361aa944cfff6545a16522ce187
/usr/lib/.build-id/4c
/usr/lib/.build-id/4c/8c2a327e90fc906d08d71f6a6e0cebd31c7ca1
/usr/lib/.build-id/52
/usr/lib/.build-id/52/043e0a8ccbea644055e00a7a54152ad5215db0
/usr/lib/.build-id/9e
/usr/lib/.build-id/9e/742350774b6f2a1765e45360bb41ce03de8ea6
/usr/lib/.build-id/a8
/usr/lib/.build-id/a8/4d65696fddf26e5bbe682227925e2ce7639166
/usr/lib/.build-id/b3
/usr/lib/.build-id/b3/d2f18dc79a648e1e84ec0122ee3ce6a57a6218
/usr/lib/.build-id/ba
/usr/lib/.build-id/ba/00b52d2da7ed67d05897de1d8ae2c6a3deee3f
/usr/lib/libproj.so.25
/usr/lib/libproj.so.25.9.6.0
/usr/share/bash-completion/completions/projinfo
/usr/bin/cct
/usr/bin/cs2cs
/usr/bin/geod
/usr/bin/gie
/usr/bin/invgeod
/usr/bin/invproj
/usr/bin/proj
/usr/bin/projinfo
/usr/bin/projsync
/usr/lib/.build-id
/usr/lib/.build-id/74
/usr/lib/.build-id/74/6ac64a6caad8b2fa1ae3533e04bfc1fceaa90d
/usr/lib/.build-id/9d
/usr/lib/.build-id/9d/830296bb5847f587732206b121e36efb66854c
/usr/lib/.build-id/9d/ca72ccefe579fd0e3b9a8cca4b8bdbe525d400
/usr/lib/.build-id/a5
/usr/lib/.build-id/a5/2a2c7c978bac15755aa59789b10b7f2d3da426
/usr/lib/.build-id/bd
/usr/lib/.build-id/bd/996b2208263609e2020fcf76e057bac96185b5
/usr/lib/.build-id/c9
/usr/lib/.build-id/c9/b53512638a0545915685d9364ed3a341597960
/usr/lib/.build-id/cc
/usr/lib/.build-id/cc/0ddbafced12601640344ee448b0f4a57a53513
/usr/lib/.build-id/cc/70c873a4bee5f136b7cb5a4e0d6f5b480e0586
/usr/lib64/libproj.so.25
/usr/lib64/libproj.so.25.9.6.0
/usr/share/bash-completion/completions/projinfo
```
as you can see there is `libproj.so.25`, there is no `libproj.so.22`. So no, there is not the wrong version of proj in Rocky repositories since it is exactly the same as RHEL9. Now, let’s take a look to see if we can see if `libproj.so.22` exists:
```auto
root@rhel9:~# dnf provides */libproj.so.22
Updating Subscription Management repositories.
Last metadata expiration check: 0:03:30 ago on Thu 11 Dec 2025 10:38:43 AM CET.
Error: No matches found. If searching for a file, try specifying the full path or using a wildcard prefix ("*/") at the beginning.
```
no, there is no `libproj.so.22` in RHEL9. Or maybe you can ask them which repo it is available in? Since it’s not available in the default common repositories. The better bet is for them to actually update their code to use the newer versions. Their package is dependent on the OS not the other way around. So if the OS updates proj to a newer version, then they have to update their package/code to use it.
---
### Author:  [@mats](https://forums.rockylinux.org/u/mats)
#### Post date: [December 11, 2025, 9:59am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/3 "2025-12-11T09:59:17Z")
Thanks for your very swift reply. This is kind of also the same conclusion I got to, RockyLinux9 does not provide libproj.so.22. It did however used to do so, as an older built image does have it installed through dnf.
If it is simply the case that RHEL (and thus RockyLinux) 9 updated their repos to include the newer version of proj in stead of the old one, then that would indeed just mean that baltrad needs to update their rpm, which is why I asked them first.
They said however that RHEL9 still provides libproj.so.22 in stead of libproj.so.25, which is why I interpreted this as a RockyLinux bug. Looking at your reply I think that they have maybe been wrong on this. I relayed your reply back to them.
Thanks for your help!
---
### Author:  [@iwalker](https://forums.rockylinux.org/u/iwalker)
#### Post date: [December 11, 2025, 10:04am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/4 "2025-12-11T10:04:15Z")
> [@mats](#):
>
> They said however that RHEL9 still provides libproj.so.22 in stead of libproj.so.25, which is why I interpreted this as a RockyLinux bug. Looking at your reply I think that they have maybe been wrong on this. I relayed your reply back to them.
The question to ask them at this point is, if it exists, then where is it? Because as shown above it doesn’t exist in ANY of the default RHEL9 repositories.
One more thing to add, I’ll give a small example below to show the difference. You’ll have noticed in my previous post I used the `--showduplicates` parameter, to see if RHEL9 showed multiple proj packages of which it doesn’t. Now, if I repeat that for say nano:
```auto
root@rhel9:~# dnf list nano --showduplicates
Updating Subscription Management repositories.
Last metadata expiration check: 0:00:15 ago on Thu 11 Dec 2025 10:56:43 AM CET.
Installed Packages
nano.x86_64 5.6.1-7.el9 @rhel-9-for-x86_64-baseos-rpms
Available Packages
nano.x86_64 5.6.1-5.el9 rhel-9-for-x86_64-baseos-rpms
nano.x86_64 5.6.1-6.el9 rhel-9-for-x86_64-baseos-rpms
nano.x86_64 5.6.1-7.el9 rhel-9-for-x86_64-baseos-rpms
```
as you can see, we can choose a previous version. Had a previous version of proj been available in RHEL9, we’d have been able to install it, be it the version from 9.0, 9.1, 9.2 or whatever. Unfortunately that is not the case, so if proj does exist as an older version then the question is in which repository? Because it doesn’t appear in the main repositories for the distribution.
Now, let’s repeat the same nano example on Rocky9.
```auto
root@rocky9:~# dnf list --showduplicates nano
Last metadata expiration check: 0:02:12 ago on Thu 11 Dec 2025 10:55:32 AM CET.
Installed Packages
nano.x86_64 5.6.1-7.el9 @baseos
Available Packages
nano.x86_64 5.6.1-7.el9 baseos
```
as you can see here, it’s only showing the latest. And there is a big reason for this. With Rocky, only the latest release is supported, so you will only see packages available in the current version. Therefore, the `--showduplicates` command will not help if older packages are available. Rocky only supports the latest release. This means, once a new release is available, like 9.7 then this is the only one supported. Sure, you can stay on Rocky 9.0 or whatever if you want, but then any packages you install later will become a mix of 9.0 and 9.7 packages which would also be an unsupported scenario.
Rocky doesn’t support version pinning either, so if that is something you need then your real option is to pay and use RHEL9 instead. But irrespective of this, if someone is making an rpm for a Linux distribution, then they should be ensuring that they keep it up-to-date and provide new versions that utilise the newer packages when a system is updated. They cannot lock it to an old package version, or expect people to downgrade packages just to use their rpm.
---
### Author:  [@mats](https://forums.rockylinux.org/u/mats)
#### Post date: [December 11, 2025, 10:21am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/5 "2025-12-11T10:21:43Z")
Yeah I have been looking everywhere I could for a proj 8.2.0 version in any RedHat related repo on the internet and I cannot find it, so that is still confusing to me. As this docker image I built earlier has this version of proj installed and it was installed through dnf. So where that one came from is still a mystery.
Now this mystery does not need to be solved for me, as to me the solution seems to be clear. But it is still weird that somehow I managed to install a version of proj through dnf 2 months ago, that I can now no longer find any reference of anymore.
The commands below are from inside this docker image.
```auto
$cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.6 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.6"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.6 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
VENDOR_NAME="RESF"
VENDOR_URL="https://resf.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.6"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.6"
$find -wholename "*libproj.so*"
./usr/lib64/libproj.so.22.2.0
./usr/lib64/libproj.so
./usr/lib64/libproj.so.22
```
---
### Author:  [@mats](https://forums.rockylinux.org/u/mats)
#### Post date: [December 11, 2025, 10:24am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/6 "2025-12-11T10:24:10Z")
I did `dnf list` on proj-devel in this docker image and this is what I get:
```auto
$dnf list proj-devel
Last metadata expiration check: 0:01:14 ago on Thu Dec 11 10:22:11 2025.
Installed Packages
proj-devel.x86_64 8.2.0-1.el9 @epel
Available Packages
proj-devel.i686 9.6.0-2.el9 crb
proj-devel.x86_64 9.6.0-2.el9 crb
```
and same for `proj`
```auto
$dnf list proj
Last metadata expiration check: 0:02:18 ago on Thu Dec 11 10:22:11 2025.
Installed Packages
proj.x86_64 8.2.0-1.el9 @epel
Available Packages
proj.i686 9.6.0-2.el9 appstream
proj.x86_64 9.6.0-2.el9 appstream
```
So it was at some point available through dnf at least.
---
### Author:  [@mats](https://forums.rockylinux.org/u/mats)
#### Post date: [December 11, 2025, 10:38am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/7 "2025-12-11T10:38:12Z")
Looks to me like this version was at some point available in EPEL ([Index of /pub/epel/9/Everything/x86\_64/Packages/p](https://web.archive.org/web/20230810175542/https://dl.fedoraproject.org/pub/epel/9/Everything/x86_64/Packages/p/)), but now it is no longer on there. Currently it is still available through crb and appstream, but it is a different version.
---
### Author:  [@iwalker](https://forums.rockylinux.org/u/iwalker)
#### Post date: [December 11, 2025, 10:39am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/8 "2025-12-11T10:39:11Z")
> [@mats](#):
>
> `/usr/lib64/libproj.so.22`
Try
```auto
rpm -qf /usr/lib64/libproj.so.22
```
and then:
```auto
dnf info proj
```
since we need to find out more info about the package itself. Assuming of course that proj will be the package that libproj.so.22 belongs to. If a different package, then dnf info on that packagename.
---
### Author:  [@mats](https://forums.rockylinux.org/u/mats)
#### Post date: [December 11, 2025, 10:41am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/9 "2025-12-11T10:41:05Z")
```auto
$rpm -qf /usr/lib64/libproj.so.22
proj-8.2.0-1.el9.x86_64
$dnf info proj
Baltrad 27 kB/s | 3.0 kB 00:00
Baltrad 138 kB/s | 37 kB 00:00
Extra Packages for Enterprise Linux 9 - x86_64 81 kB/s | 34 kB 00:00
Extra Packages for Enterprise Linux 9 - x86_64 8.1 MB/s | 20 MB 00:02
Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64 2.7 kB/s | 993 B 00:00
Rocky Linux 9 - BaseOS 21 kB/s | 4.3 kB 00:00
Rocky Linux 9 - BaseOS 6.0 MB/s | 5.1 MB 00:00
Rocky Linux 9 - AppStream 21 kB/s | 4.8 kB 00:00
Rocky Linux 9 - AppStream 9.3 MB/s | 10 MB 00:01
Rocky Linux 9 - CRB 21 kB/s | 4.8 kB 00:00
Rocky Linux 9 - CRB 4.3 MB/s | 2.8 MB 00:00
Rocky Linux 9 - Extras 15 kB/s | 3.1 kB 00:00
Rocky Linux 9 - Extras 61 kB/s | 16 kB 00:00
Installed Packages
Name : proj
Version : 8.2.0
Release : 1.el9
Architecture : x86_64
Size : 12 M
Source : proj-8.2.0-1.el9.src.rpm
Repository : @System
From repo : epel
Summary : Cartographic projection software (PROJ)
URL : https://proj.org
License : MIT
Description : Proj and invproj perform respective forward and inverse transformation of
: cartographic data to or from cartesian data with a wide range of selectable
: projection functions.
Available Packages
Name : proj
Version : 9.6.0
Release : 2.el9
Architecture : x86_64
Size : 1.5 M
Source : proj-9.6.0-2.el9.src.rpm
Repository : appstream
Summary : Cartographic projection software (PROJ)
URL : https://proj.org
License : MIT
Description : Proj and invproj perform respective forward and inverse transformation of
: cartographic data to or from cartesian data with a wide range of selectable
: projection functions.
Name : proj
Version : 9.6.0
Release : 2.el9
Architecture : i686
Size : 1.6 M
Source : proj-9.6.0-2.el9.src.rpm
Repository : appstream
Summary : Cartographic projection software (PROJ)
URL : https://proj.org
License : MIT
Description : Proj and invproj perform respective forward and inverse transformation of
: cartographic data to or from cartesian data with a wide range of selectable
: projection functions.
```
---
### Author:  [@iwalker](https://forums.rockylinux.org/u/iwalker)
#### Post date: [December 11, 2025, 10:41am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/10 "2025-12-11T10:41:31Z")
So there the answer is. proj-8.2.0 is from EPEL. So it was never a part of RHEL9 or Rocky9 - was a third-party rpm from EPEL.
---
### Author:  [@iwalker](https://forums.rockylinux.org/u/iwalker)
#### Post date: [December 11, 2025, 10:48am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/11 "2025-12-11T10:48:28Z")
Searching [pkgs.org](http://pkgs.org) it no longer exists in EPEL, since it has now been superceded by proj in RHEL9 and therefore removed from EPEL most likely due to this.
So, all that is left now, is for the developers of that package you use to update their dependencies since it’s no longer available. It is now their problem.
The other alternative, is finding the source for that particular version to build it yourself.
---
### Author:  [@mats](https://forums.rockylinux.org/u/mats)
#### Post date: [December 11, 2025, 10:50am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/12 "2025-12-11T10:50:12Z")
Yeah indeed, and it looks like it was removed there and now it is available as a different version from appstream and crb. Still seems to me that the baltrad version in the rpm just needs to be updated to this newer version then.
Thanks for your help, I don’t have that much experience with RedHat like linux versions and all these different RPMs, but now I think I have a very clear picture of what is going on.
---
### Author:  [@iwalker](https://forums.rockylinux.org/u/iwalker)
#### Post date: [December 11, 2025, 10:52am UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/13 "2025-12-11T10:52:18Z")
> [@mats](#):
>
> Thanks for your help, I don’t have that much experience with RedHat like linux versions and all these different RPMs, but now I think I have a very clear picture of what is going on.
It will be no different for other distros, like Debian etc since once packages are updated, then people need to rebuild their package dependencies accordingly. They have basically not updated their rpm or code since basing it on proj-8.2.0. So if they are still working on that project, they need to put in the effort to keep it up-to-date 🙂
---
### Author:  [@gerry666uk](https://forums.rockylinux.org/u/gerry666uk)
#### Post date: [December 11, 2025, 3:32pm UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/14 "2025-12-11T15:32:34Z")
> [@iwalker](#):
>
> And there is a big reason for this. With Rocky, only the latest release is supported, so you will only see packages available in the current version. Therefore, the `--showduplicates` command will not help
It would be great if we could have 'show duplicates" in Rocky.
---
### Author:  [@iwalker](https://forums.rockylinux.org/u/iwalker)
#### Post date: [December 11, 2025, 3:51pm UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/15 "2025-12-11T15:51:18Z")
For Rocky repositories, unlikely due to the way only the current release is supported. If multiple versions of a package were released in 9.7, then those duplicates would also show up.
For other configured repositories, eg: like my example of my own repository below:
```auto
root@rocky9:~# dnf --showduplicates list tabby-terminal
Last metadata expiration check: 0:01:16 ago on Thu 11 Dec 2025 04:45:08 PM CET.
Available Packages
tabby-terminal.x86_64 1.0.228-1 myrepo
tabby-terminal.x86_64 1.0.229-1 myrepo
```
which is a collection of rpm’s I download and install via that, rather than install them from the command line locally, you can clearly see that tha parameter still works.
Theoretically, if I was to configure manually multiple Rocky repos, for example baseos-9.7, appstream-9.7, baseos-9.6, appstream-9.6, etc, etc I could then utilise the parameter to gain access to all versions of a particular package across the entire 9.x release.
---
### Author:  [@system](https://forums.rockylinux.org/u/system)
#### Post date: [February 9, 2026, 3:51pm UTC](https://forums.rockylinux.org/t/wrong-version-of-proj-in-rocky-linux-9-7-repos/20040/16 "2026-02-09T15:51:55Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.