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.
The libpq library is part of the postgresql codebase. We have previously decided to separate it downstream and package it as a separate component.
This means that different versions of postgresql are built modularly against a single non-modular libpq library.
Upstream releases minor updates for all supported major version at once like this:
13.0 -> 13.1
12.4 -> 12.5
11.9 -> 11.10
10.14 -> 10.15
9.6.19 -> 9.6.20
9.5.23 -> 9.5.24
This means that to be able to rebase all postgresql streams (13,12,11,10,9.6) to their latest minor release versions, first we need to rebase the libpq library to the (in this case) 13.1 version.
In that scenario, all streams except postgresql:13 are being built against different version of libpq, even though there is the correct libpq version in each postgresql source tarball for each stream, as libpq is part of its codebase.
Historically, this way of packaging postgresql with separated libpq worked. However, upstream stated that they do not guarantee such compatibility, and postgresql was never intended to be built against external libpq.
With the release version 13.1, we encountered some (thankfully) minor incompatibilities, causing us to patch downstream all streams up to postgresql:13.
This new solution is not a classic bundle. It's a return to how postgresql is supposed to be built, while keeping a separate libpq package for users.
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.
The only change here is the symbol version, as they are versioned downstream, and a mistake happened regarding that patch on rebase to the version 12.x. There is no upstream change, nor are any symbols actually being changed.