On Fri, Jan 29, 2021 at 04:17:02PM +0100, Patrik Novotny wrote: > > > > 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. Thank you for the explanation. Zbyszek > 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. _______________________________________________ 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
