I am using the latest Fedora 38 on my 64-bit Intel machine. Here is what I am getting:
# dnf clean all
[...]
# dnf update
Last metadata expiration check: 0:00:14 ago on Tue 24 Oct 2023 09:14:12 AM CDT.
Dependencies resolved.
Problem: package libpq-devel-15.3-1.fc38.x86_64 from @System requires libpq(x86-64) = 15.3-1.fc38, but none of the providers can be installed
- package libpq5-16.0-42PGDG.f38.x86_64 from pgAdmin4 obsoletes libpq provided by libpq-15.3-1.fc38.x86_64 from @System
- package libpq5-16.0-42PGDG.f38.x86_64 from pgAdmin4 obsoletes libpq provided by libpq-15.3-1.fc38.x86_64 from updates
- cannot install the best update candidate for package libpq-devel-15.3-1.fc38.x86_64
- cannot install the best update candidate for package libpq-15.3-1.fc38.x86_64
Nothing to do.
Complete!
#
This has been going on for at least a week. Sure appreciate any help.
It appears that you have installed a 3rd party repo, “pgAdmin4” that conflicts with the Fedora repos.
You have three options:
Fedora already ships pgadmin4 in the repos already, so remove the pgadmin4 repo you installed and sudo dnf distro-sync and just use the Fedora shipped pgAdmin
If you really want to prefer that repo over the Fedora updates, then you can try adding excludepkgs=pgadmin4*,libpq5,libpq-devel to /etc/yum.repos.d/fedora-updates.repo with the understanding that updates to those packages will come from the pgadmin4 repo and not Fedora updates at that point and this may or may not cause issues with major version upgrades
Run pgadmin4 in a container from the upstream vendor of your choosing and side-step dnf repo conflicts entirely.
No. I think it is hosted by the pgAdmin group. I think I was using pgAdmin and found a bug. I then noticed that the pgAdmin group had a slightly later version so I installed that. I don’t think it actually fixed the bug I found though.
This is a perfect example of why a user should not just enable and leave enabled a 3rd party repo – particularly one that is used primarily by developers.
Having such a repo enabled often causes the dependency issues seen here.
It is quite normal for a user to assist in tracking bugs, but something else entirely to leave such a repo enabled and forget about it until the dependencies crop up in another situation – such as a routine update.