Package kea-libs requires libpq.so library. For this purpose, there is a libpq component providing an unversioned library that should be used within every single Postgresql version. It provides stable backward-compatible ABI for communication with postgresql server. So, it's a required option for usage.

In the Postgresql package, there is also a postgresql-private-libs sub-package that provides libpq.so.private. However, this library is intended to be used only internally by the postgresql-server. (The reason for such architecture is the support of multiple Postgresql versions in a single RHEL; the important fact is that we do not allow parallel installation of Postgresql servers.)

This situation could lead to unwanted behavior in the feature. Problematic scenario followed:

1. install kea-libs
   1.  it installs also postgresql-private-libs in the transaction (version 16 - the default one)
2.  install postgresql-server (version 16)
3. Works fine now.

But once the user wants to upgrade postgresql-server (let's say postgresql17)
it will cause conflicting request because parallel installation is not allowed, and postgresql-private-libs( version 16) requires kea and postgresql17-server requires postgresql-private-libs( version 17).

Since libraries libpq.so and libpq.so.private are identical (at least now in c10s) kea-libs should requires libpq.so from libpq package. It would avoid the problematic situation described above.

kea-libs brew build https://brewweb.engineering.redhat.com/brew/rpminfo?rpmID=13318541
postgresql-private-devel build https://brewweb.engineering.redhat.com/brew/rpminfo?rpmID=13345580
libpq build https://brewweb.engineering.redhat.com/brew/rpminfo?rpmID=13345537