-
Bug
-
Resolution: Unresolved
-
Undefined
-
rhel-10.0.beta
-
None
-
sst_cs_infra_services
-
ssg_core_services
-
2
-
False
-
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:
- install kea-libs
- it installs also postgresql-private-libs in the transaction (version 16 - the default one)
- install postgresql-server (version 16)
- 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