On Tue, Jan 12, 2021 at 03:57:02PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/PostgreSQL_13 > > > == Summary == > Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora > from version 12 to version 13 in the non-modular (main) builds. > > Also, there will be a design change in postgresql modular packaging > regarding the external libpq library ensuring future build time > compatibility. More information in the Detailed Description section. > > == Owner == > * Name: [[User:panovotn| Patrik Novotny]] > * Email: panovotn@xxxxxxxxxx > > > == Detailed Description == > Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora > from version 12 to version 13 in the non-modular (main) builds. > > This also involves updating and rebuilding the PostgreSQL plugins that > depend on postgresql server. > > There will also be a change to the packaging of postgresql modules, as > with those, the external libpq library can be potentially problematic > upon upstream releases. > > As postgresql packages are built against the separated libpq package, > an incompatibility between major versions can occur with new minor > upstream releases. For example, when building postgresql version 12.4 > against libpq version 13.1. > > To keep the benefits of having separately maintained libpq library, > libpq stays as a separate package. > > However, to solve the potential issues with the postgresql builds, we > will bundle libpq with a downstream changed SONAME within each > postgresql release. The postgresql will be built against this libpq. > > This bundled libpq will always be the same version as the > corresponding postgresql as they will share the same codebase. As the > libpq SONAME will be changed downstream to a non-standard SONAME, and > separate libpq package with standard SONAME will be provided, this > change won't affect the user experience for those components. Hmm, this sounds rather complicated and risky. Do I get this right that postgresql will bundle a copy of libpq, and a separate unbundled libpq will be provided? Why not just include a specific Requires on a specific version of libpq? (Maybe something like Requires:libpq(%_isa)>=x.y.z and libpq(%_isa)<x.y.z^ or whatever the best syntax is). There are plenty of packages which require some specific version of a separately-packages library. We don't normally use bundling in such cases. Since both packages are under the same maintainership, it should be easy enough to keep them in sync. > == Upgrade/compatibility impact == > The PostgreSQL client library (libpq component) is compatible, but > there is an issue with symbol versioning (originally reported > https://bugzilla.redhat.com/show_bug.cgi?id=1893324 was reverted, but > there is a plan to fix this properly together with this PostgreSQL > update tracked in > https://bugzilla.redhat.com/show_bug.cgi?id=1908268). So, there > shouldn't be any issues with API compatibility, but rebuild of the > depended components is necessary. Those bugs have a lot of detail... It seems that the only real solution is to retroactively bump the so version. I couldn't figure out if that is what happened upstream. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
