Re: Shared PostgreSQL libraries and symbol versioning
Re: Pavel Raiskup 2018-05-24 <101829257.nn0xsvv...@nb.usersys.redhat.com> > > Interesting, thanks. How this is implemented? What you mean by "newer > > library" -- new soname, or just a newer package build (without any other > > change) e.g.? > > I've already done some observation how libraries are handled by Debian :-) > sorry for my ignorance. If I got it right, if some packages provide > some SONAME then those must also provide the *.shlibs and *.symbols files > (in repo metadadata, apt-cache `ls -1 /var/lib/dpkg/info/libpq*.s*`) and > that info is then used to generate safe dependencies for other packages > (I mean the 'Depends' field in e.g. `apt-cache show python-psycopg2`). The whole system relies on upstream getting the SONAME right by not breaking the ABI, i.e. symbols must only be added, never removed, and never changed in semantics. For a given program with a set of symbols used, dpkg-shlibdeps then reads the *.symbols file to determine the minimum package version that this set of symbols is compatible with when linking against a shared object. (*.shlibs is the predecessor of the *.symbols system which is inferior because it only tracks a global minimum compatible version, instead of looking at each symbol individually.) > The thing is that those metadata files can be either generated > automatically (by dpkg-gensymbols at package build-time?) or have to be > maintained manually, which is the case of PostgreSQL packaging, see e.g. > change for added symbol in v10: > https://salsa.debian.org/postgresql/postgresql/commit/c3eba5c8d04177f81a7b4a043302a209f3d2d2e7 The *.symbols files maintain themselves automatically via dpkg-gensymbols at build time, but it makes sense to edit the result for more accurate (or nicer) information. For example in the change your linking to, dpkg-gensymbols might have used "10~beta1-1" as minimum version, but it's better to change that to 10~~ because it's shorter, and because all version 10 packages feature that symbol, and beta1 might just have been the first package version built. > So basically, Debian packagers seem take care of the symbol versioning > downstream, and they could have this solved automatically if upstream > tarball allowed the symbol versioning (so they could leverage the > `dpkg-gensymbols` thing, instead of the manual work). Can anyone confirm? No. Versioned symbols in shared objects have the advantage that they allow upstream to incompatibly change symbols without bumping the SONAME (provided the old version is still shipped), but they don't remove the need to declare a dependency on the *package* version where this symbol was introduced. That is not possible to extract from the upstream symbol version information, it needs to be handled on the packaging side. > It's similar with RPM, except that the tooling is seemingly less powerful; > we have to have the symbol versions baked into *.so file, otherwise it > simply doesn't work. It has some pros, :-) it motivates us more to solve > it upstream, if possible. But yeah, since we'll face the same problem in > Fedora/RHEL/CentOS -- we'll have to have the problem solved somehow > (at least downstream) ... How does RPM solve the "depend on this package version" problem? By declaring "Provides: PQencryptPasswordConn@Base" in the .so's package for each symbol? > > I don't really want to push it upstream; I'm just saying that we consider > > this to be important enough to go downstream-fix only way. At the same > > time, I'm convinced having it upstream is almost trivial change and worth > > having... So I try to offer a help. If you do this downstream-only, it might create a giant maintenance burden that you have to carry on forever, I'd think. Christoph
Re: Shared PostgreSQL libraries and symbol versioning
On Wednesday, May 23, 2018 2:23:24 PM CEST Pavel Raiskup wrote: > Thanks Stephen, > > On Wednesday, May 23, 2018 1:13:08 PM CEST Stephen Frost wrote: > > Greetings, > > > > * Pavel Raiskup (prais...@redhat.com) wrote: > > > On Thursday, May 10, 2018 12:41:40 PM CEST Pavel Raiskup wrote: > > > > On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote: > > > > > Stephen Frost writes: > > > > > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > > > > >> On 4/5/18 02:04, Pavel Raiskup wrote: > > > > > >>> As a followup thought; there are probably two major obstacles ATM > > > > > >>> - the DSOs' symbols are not yet versioned, and > > > > > >>> - the build-system doesn't seem to know how to -lpq link against > > > > > >>> external libpq.so > > > > > > > > > > > I've not looked but neither of those strike me as terribly > > > > > > difficult to > > > > > > overcome, assuming they need to be overcome. > > > > > > > > > > I'm not excited about introducing YA cross-platform difference in our > > > > > library/linking behavior without fairly strong evidence that it's > > > > > necessary. The available evidence points in the other direction. > > > > > > > > Well, but I believe it is really needed (in our case at least) - it's so > > > > important that we think about doing the symbol versioning > > > > downstream-only. > > > > > > Gently ping on this; sum-up is that we'll move libpq.so.5 into 'libpq' > > > package (with corresponding libpq-devel having libpq.so). That package is > > > likely to receive PG major version updates during one version of > > > Fedora/CentOS/RHEL version; so because of that the plan is to start symbol > > > versioning like RHPG_10@@..., e.g. 'PQinitOpenSSL@@RHPG_10'. > > > > > > I'd go with downstream change now, and I'd like to hear voices against > > > this > > > change (if there is anything obvious to you). I'd like to help having > > > this > > > as upstream opt-in of course, too, so feel free to ping me any time in > > > future. > > > > The way to try and move this forward would be to specifically address > > Tom's concern about having more differences in our library/linking > > behavior across platforms. > > It's not really that different. Linking is done the same way, except that - > when available - symbol versions are used, too (we use --version-script GNU ld > option anyways). > > > Implementing this change in a way that makes it very specific to one > > platform > > is surely going in the wrong direction. > > Please elaborate. It shouldn't really cause troubles IMO. > > > Have you tried talking to the Debian and the maintainers of other platforms > > to > > get their input on such a change? Are they supportive of it, would they > > like > > to see upstream do it, what would make sense here if upstream did it? > > CCing Christoph. > > > Are there still platforms we care about which wouldn't be able to support > > this? > > I think so - if there's no such linker support, but it shouldn't really > matter. > > > Is there a way to make it work across all platforms? > > No, seems like it's GNU feature, see GNU ld manual [1], plus the dsohowto > reference there. > > > The other side of this is: why isn't the packaging system handling this? > > It would (RPM), if there were the symbol versions. > > > On Debian, at least, if you build a package with a newer version of a > > library, then that package will depend on that newer version to be > > installed; why isn't that enough for the RPM-based systems too? > > Older packages will still run against the newer libpq unless/until we > > make a backwards-incompatible change, which is rather rare. > > Interesting, thanks. How this is implemented? What you mean by "newer > library" -- new soname, or just a newer package build (without any other > change) e.g.? I've already done some observation how libraries are handled by Debian :-) sorry for my ignorance. If I got it right, if some packages provide some SONAME then those must also provide the *.shlibs and *.symbols files (in repo metadadata, apt-cache `ls -1 /var/lib/dpkg/info/libpq*.s*`) and that info is then used to generate safe dependencies for other packages (I mean the 'Depends' field in e.g. `apt-cache show python-psycopg2`). The thing is that those metadata files can be either generated automatically (by dpkg-gensymbols at package build-time?) or have to be maintained manually, which is the case of PostgreSQL packaging, see e.g. change for added symbol in v10: https://salsa.debian.org/postgresql/postgresql/commit/c3eba5c8d04177f81a7b4a043302a209f3d2d2e7 So basically, Debian packagers seem take care of the symbol versioning downstream, and they could have this solved automatically if upstream tarball allowed the symbol versioning (so they could leverage the `dpkg-gensymbols` thing, instead of the manual work). Can anyone confirm? It's similar with RPM, except that the tooling is seemingly less powerful; we have to have the sym
Re: Shared PostgreSQL libraries and symbol versioning
Thanks Stephen, On Wednesday, May 23, 2018 1:13:08 PM CEST Stephen Frost wrote: > Greetings, > > * Pavel Raiskup (prais...@redhat.com) wrote: > > On Thursday, May 10, 2018 12:41:40 PM CEST Pavel Raiskup wrote: > > > On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote: > > > > Stephen Frost writes: > > > > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > > > >> On 4/5/18 02:04, Pavel Raiskup wrote: > > > > >>> As a followup thought; there are probably two major obstacles ATM > > > > >>> - the DSOs' symbols are not yet versioned, and > > > > >>> - the build-system doesn't seem to know how to -lpq link against > > > > >>> external libpq.so > > > > > > > > > I've not looked but neither of those strike me as terribly difficult > > > > > to > > > > > overcome, assuming they need to be overcome. > > > > > > > > I'm not excited about introducing YA cross-platform difference in our > > > > library/linking behavior without fairly strong evidence that it's > > > > necessary. The available evidence points in the other direction. > > > > > > Well, but I believe it is really needed (in our case at least) - it's so > > > important that we think about doing the symbol versioning downstream-only. > > > > Gently ping on this; sum-up is that we'll move libpq.so.5 into 'libpq' > > package (with corresponding libpq-devel having libpq.so). That package is > > likely to receive PG major version updates during one version of > > Fedora/CentOS/RHEL version; so because of that the plan is to start symbol > > versioning like RHPG_10@@..., e.g. 'PQinitOpenSSL@@RHPG_10'. > > > > I'd go with downstream change now, and I'd like to hear voices against this > > change (if there is anything obvious to you). I'd like to help having this > > as upstream opt-in of course, too, so feel free to ping me any time in > > future. > > The way to try and move this forward would be to specifically address > Tom's concern about having more differences in our library/linking > behavior across platforms. It's not really that different. Linking is done the same way, except that - when available - symbol versions are used, too (we use --version-script GNU ld option anyways). > Implementing this change in a way that makes it very specific to one platform > is surely going in the wrong direction. Please elaborate. It shouldn't really cause troubles IMO. > Have you tried talking to the Debian and the maintainers of other platforms to > get their input on such a change? Are they supportive of it, would they like > to see upstream do it, what would make sense here if upstream did it? CCing Christoph. > Are there still platforms we care about which wouldn't be able to support > this? I think so - if there's no such linker support, but it shouldn't really matter. > Is there a way to make it work across all platforms? No, seems like it's GNU feature, see GNU ld manual [1], plus the dsohowto reference there. > The other side of this is: why isn't the packaging system handling this? It would (RPM), if there were the symbol versions. > On Debian, at least, if you build a package with a newer version of a > library, then that package will depend on that newer version to be > installed; why isn't that enough for the RPM-based systems too? > Older packages will still run against the newer libpq unless/until we > make a backwards-incompatible change, which is rather rare. Interesting, thanks. How this is implemented? What you mean by "newer library" -- new soname, or just a newer package build (without any other change) e.g.? > > > As I said, we'd like to provide multiple major PG versions, but only one > > > set of PG libraries. But as the time will continue, supporting newer PG > > > major versions will require updating the system's default 'libpq.so.5', > > > potentially for the newly added symbols. If we had in our RPMs versioned > > > symbols, RPM would for free guard us against wrong package installations > > > (IOW RPM would guarantee that users won't install packages depending on > > > newer symbols unless also newer 'libpq.so.5' is installed). Without > > > lib symbol versions, there's no **easy** way around this. > > I'm failing to see why symbol versioning is the way to prevent this from > happening. That's the RPM automation; more concretely: 1. if libpq.so.5 library provides symbol versions, then the RPM package that provides the library also has some info for depsolver (so called "Provides") about what symbol versions that particular RPM provides 2. if you build-time link some package against ^^^ that library, then the RPM will provide the info for depsolver (so called "Requires") what symbol versions that package _requires_. Note that it's somewhat "optimal", because if the package only requires symbols provided by v9.6 then -- even though you build against v10 -- the v10 dependancy isn't added and your built package can be installed against v9.6 > > > Debian folks claim
Re: Shared PostgreSQL libraries and symbol versioning
Greetings, * Pavel Raiskup (prais...@redhat.com) wrote: > On Thursday, May 10, 2018 12:41:40 PM CEST Pavel Raiskup wrote: > > On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote: > > > Stephen Frost writes: > > > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > > >> On 4/5/18 02:04, Pavel Raiskup wrote: > > > >>> As a followup thought; there are probably two major obstacles ATM > > > >>> - the DSOs' symbols are not yet versioned, and > > > >>> - the build-system doesn't seem to know how to -lpq link against > > > >>> external libpq.so > > > > > > > I've not looked but neither of those strike me as terribly difficult to > > > > overcome, assuming they need to be overcome. > > > > > > I'm not excited about introducing YA cross-platform difference in our > > > library/linking behavior without fairly strong evidence that it's > > > necessary. The available evidence points in the other direction. > > > > Well, but I believe it is really needed (in our case at least) - it's so > > important that we think about doing the symbol versioning downstream-only. > > Gently ping on this; sum-up is that we'll move libpq.so.5 into 'libpq' > package (with corresponding libpq-devel having libpq.so). That package is > likely to receive PG major version updates during one version of > Fedora/CentOS/RHEL version; so because of that the plan is to start symbol > versioning like RHPG_10@@..., e.g. 'PQinitOpenSSL@@RHPG_10'. > > I'd go with downstream change now, and I'd like to hear voices against this > change (if there is anything obvious to you). I'd like to help having this > as upstream opt-in of course, too, so feel free to ping me any time in future. The way to try and move this forward would be to specifically address Tom's concern about having more differences in our library/linking behavior across platforms. Implementing this change in a way that makes it very specific to one platform is surely going in the wrong direction. Have you tried talking to the Debian and the maintainers of other platforms to get their input on such a change? Are they supportive of it, would they like to see upstream do it, what would make sense here if upstream did it? Are there still platforms we care about which wouldn't be able to support this? Is there a way to make it work across all platforms? The other side of this is: why isn't the packaging system handling this? On Debian, at least, if you build a package with a newer version of a library, then that package will depend on that newer version to be installed; why isn't that enough for the RPM-based systems too? Older packages will still run against the newer libpq unless/until we make a backwards-incompatible change, which is rather rare. > > As I said, we'd like to provide multiple major PG versions, but only one > > set of PG libraries. But as the time will continue, supporting newer PG > > major versions will require updating the system's default 'libpq.so.5', > > potentially for the newly added symbols. If we had in our RPMs versioned > > symbols, RPM would for free guard us against wrong package installations > > (IOW RPM would guarantee that users won't install packages depending on > > newer symbols unless also newer 'libpq.so.5' is installed). Without > > lib symbol versions, there's no **easy** way around this. I'm failing to see why symbol versioning is the way to prevent this from happening. > > Debian folks claim they don't have a problem with symbol versioning even > > though they have the same installation pattern since ever, but IMO that's > > because (as far as I understand how all of this is done on Debian): > > > > - Debian doesn't have that long support life cycle, so new symbols are > > to occur less likely > > > > - Debian actually provides officially only one version of PG stack > > (including libraries), the rest is provided through postgresql.org > > repositories (one could say "third party", even though those are > > probably the same maintainers). So for Debian, it's really unlikely to > > build system package against updated 'libpq.so.5' which comes from > > the "third party" repo. I suspect you've actually missed the big point here that Debian has versioned dependencies for libraries, provided by dpkg, and that they track the new symbol additions and if an application is built against a newer library which has new symbols then that application's package will Depend on that newer version of the library. What it sounds like you're saying here is that RPM will do that too- but only through the use of symbol versioning. > > I mean, worthless saying that Debian packaging would benefit from > > versioned symbols too (== it would be safe to update system-wide package), > > but it would be really awesome to have consistent (upstream blessed) way > > to do the versioning. On this point, I could possibly agree. Symbol versioning is something I'm a fan of in general but we do need to think about the concer
Re: Shared PostgreSQL libraries and symbol versioning
On Thursday, May 10, 2018 12:41:40 PM CEST Pavel Raiskup wrote: > On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote: > > Stephen Frost writes: > > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > >> On 4/5/18 02:04, Pavel Raiskup wrote: > > >>> As a followup thought; there are probably two major obstacles ATM > > >>> - the DSOs' symbols are not yet versioned, and > > >>> - the build-system doesn't seem to know how to -lpq link against > > >>> external libpq.so > > > > > I've not looked but neither of those strike me as terribly difficult to > > > overcome, assuming they need to be overcome. > > > > I'm not excited about introducing YA cross-platform difference in our > > library/linking behavior without fairly strong evidence that it's > > necessary. The available evidence points in the other direction. > > Well, but I believe it is really needed (in our case at least) - it's so > important that we think about doing the symbol versioning downstream-only. Gently ping on this; sum-up is that we'll move libpq.so.5 into 'libpq' package (with corresponding libpq-devel having libpq.so). That package is likely to receive PG major version updates during one version of Fedora/CentOS/RHEL version; so because of that the plan is to start symbol versioning like RHPG_10@@..., e.g. 'PQinitOpenSSL@@RHPG_10'. I'd go with downstream change now, and I'd like to hear voices against this change (if there is anything obvious to you). I'd like to help having this as upstream opt-in of course, too, so feel free to ping me any time in future. Pavel > I wouldn't bother you much with this, but it's worth keeping you at least > well informed since - if we moved that direction - there would soon exist > binaries in the wild linked against versioned PG shared libraries, and > those would raise ugly runtime linking warnings if used on systems where > are non-versioned PG libs (it's no problem vice-versa). > > As I said, we'd like to provide multiple major PG versions, but only one > set of PG libraries. But as the time will continue, supporting newer PG > major versions will require updating the system's default 'libpq.so.5', > potentially for the newly added symbols. If we had in our RPMs versioned > symbols, RPM would for free guard us against wrong package installations > (IOW RPM would guarantee that users won't install packages depending on > newer symbols unless also newer 'libpq.so.5' is installed). Without > lib symbol versions, there's no **easy** way around this. > > Debian folks claim they don't have a problem with symbol versioning even > though they have the same installation pattern since ever, but IMO that's > because (as far as I understand how all of this is done on Debian): > > - Debian doesn't have that long support life cycle, so new symbols are > to occur less likely > > - Debian actually provides officially only one version of PG stack > (including libraries), the rest is provided through postgresql.org > repositories (one could say "third party", even though those are > probably the same maintainers). So for Debian, it's really unlikely to > build system package against updated 'libpq.so.5' which comes from > the "third party" repo. > > I mean, worthless saying that Debian packaging would benefit from > versioned symbols too (== it would be safe to update system-wide package), > but it would be really awesome to have consistent (upstream blessed) way > to do the versioning. > > As for how it would be done downstream-only: Have a look at the > 'symbol-versioning' patch attached. Sorry for me being verbose here and > there.. It's pretty narrow patch luckily; because the buildsystem is > already GNU ld friendly. I implemented the new 'exports.txt' parser in > relatively portable /bin/sh, but I can (probably less portably) implement > that in awk too. Or anything, please tell. > > > As for linking against an external .so, commit dddfc4cb2 just went to > > some lengths to make sure that that *wouldn't* happen. But as long > > as all the builds expect libpq.so to end up in the same place after > > installation, I doubt it matters much what happens at build time. > > You just need to control which build actually installs it. > > Agreed, but we can build-time link against system's libpq.so pretty easily > too. E.g. by something like the attached 'no-libs' patch. Could we have > something like this as upstream ./configure opt-in? > > --- > Overall, what are your feelings? I'd be really glad to go through more > formal patch submission, those attachments are here just to have something > more > concrete in hand for the discussion purposes. > > Pavel > > > regards, tom lane > > > >
Re: Shared PostgreSQL libraries and symbol versioning
On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote: > Stephen Frost writes: > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > >> On 4/5/18 02:04, Pavel Raiskup wrote: > >>> As a followup thought; there are probably two major obstacles ATM > >>> - the DSOs' symbols are not yet versioned, and > >>> - the build-system doesn't seem to know how to -lpq link against > >>> external libpq.so > > > I've not looked but neither of those strike me as terribly difficult to > > overcome, assuming they need to be overcome. > > I'm not excited about introducing YA cross-platform difference in our > library/linking behavior without fairly strong evidence that it's > necessary. The available evidence points in the other direction. Well, but I believe it is really needed (in our case at least) - it's so important that we think about doing the symbol versioning downstream-only. I wouldn't bother you much with this, but it's worth keeping you at least well informed since - if we moved that direction - there would soon exist binaries in the wild linked against versioned PG shared libraries, and those would raise ugly runtime linking warnings if used on systems where are non-versioned PG libs (it's no problem vice-versa). As I said, we'd like to provide multiple major PG versions, but only one set of PG libraries. But as the time will continue, supporting newer PG major versions will require updating the system's default 'libpq.so.5', potentially for the newly added symbols. If we had in our RPMs versioned symbols, RPM would for free guard us against wrong package installations (IOW RPM would guarantee that users won't install packages depending on newer symbols unless also newer 'libpq.so.5' is installed). Without lib symbol versions, there's no **easy** way around this. Debian folks claim they don't have a problem with symbol versioning even though they have the same installation pattern since ever, but IMO that's because (as far as I understand how all of this is done on Debian): - Debian doesn't have that long support life cycle, so new symbols are to occur less likely - Debian actually provides officially only one version of PG stack (including libraries), the rest is provided through postgresql.org repositories (one could say "third party", even though those are probably the same maintainers). So for Debian, it's really unlikely to build system package against updated 'libpq.so.5' which comes from the "third party" repo. I mean, worthless saying that Debian packaging would benefit from versioned symbols too (== it would be safe to update system-wide package), but it would be really awesome to have consistent (upstream blessed) way to do the versioning. As for how it would be done downstream-only: Have a look at the 'symbol-versioning' patch attached. Sorry for me being verbose here and there.. It's pretty narrow patch luckily; because the buildsystem is already GNU ld friendly. I implemented the new 'exports.txt' parser in relatively portable /bin/sh, but I can (probably less portably) implement that in awk too. Or anything, please tell. > As for linking against an external .so, commit dddfc4cb2 just went to > some lengths to make sure that that *wouldn't* happen. But as long > as all the builds expect libpq.so to end up in the same place after > installation, I doubt it matters much what happens at build time. > You just need to control which build actually installs it. Agreed, but we can build-time link against system's libpq.so pretty easily too. E.g. by something like the attached 'no-libs' patch. Could we have something like this as upstream ./configure opt-in? --- Overall, what are your feelings? I'd be really glad to go through more formal patch submission, those attachments are here just to have something more concrete in hand for the discussion purposes. Pavel > regards, tom lane > Shared library symbol versioning (PORTNAME=linux) Even though we pay attention to never add a new shlib symbol by minor version update, this change makes the life easier for some PG distributors - for those who aim to support multiple major versions of PostgreSQL stacks - all built against one set of shared PG libraries (in other words, unless there's some SO version bump each PG library exists on such system only in one instance). For example (without symbol versioning) it might easily happen that some system's binary using PQencryptPasswordConn symbol (new in v10) is run against 'libpq.so.5' coming from v9.6. This is not terribly hard to imagine since at build-time it is likely that the binary is linked against proper (v10) version of the libpq.so.5. Such case would end up with linking issues at runtime. This problem is very likely to happen on systems with rather long term support (e.g. 10+ years) where many updates of the shared library are likely to happen during lifetime. Shlib symbol versioning then helps the package-tooling to always gu
Re: Shared PostgreSQL libraries and symbol versioning
Stephen Frost writes: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> On 4/5/18 02:04, Pavel Raiskup wrote: >>> As a followup thought; there are probably two major obstacles ATM >>> - the DSOs' symbols are not yet versioned, and >>> - the build-system doesn't seem to know how to -lpq link against >>> external libpq.so > I've not looked but neither of those strike me as terribly difficult to > overcome, assuming they need to be overcome. I'm not excited about introducing YA cross-platform difference in our library/linking behavior without fairly strong evidence that it's necessary. The available evidence points in the other direction. As for linking against an external .so, commit dddfc4cb2 just went to some lengths to make sure that that *wouldn't* happen. But as long as all the builds expect libpq.so to end up in the same place after installation, I doubt it matters much what happens at build time. You just need to control which build actually installs it. regards, tom lane
Re: Shared PostgreSQL libraries and symbol versioning
Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 4/5/18 02:04, Pavel Raiskup wrote: > > Hello, for the support of multiple versions of PostgreSQL RPM packages on > > one system, we are thinking about having only one libpq.so.5 > > (libecpg.so.6, libpgtype.so.3 respectively) supported and about building > > (linking) all the PostgreSQL package versions against that. The pattern > > would mean that we'd have to update the system-wide libraries before > > adding support for new PostgreSQL major version and that the older > > packages (say version =< 9.6) would be run against libs from newer PG > > package (say libpq.so.5 from v10). > > > > Do you think it is a good idea in general? > > yes Adding symbol versioning would probably be a good idea, yes, though we don't have as much need as others since we've really had a rather stable ABI for a long time. > > As a followup thought; there are probably two major obstacles ATM > > > > - the DSOs' symbols are not yet versioned, and > > - the build-system doesn't seem to know how to -lpq link against > > external libpq.so I've not looked but neither of those strike me as terribly difficult to overcome, assuming they need to be overcome. > It's not clear to me why you would need these, given that Debian has > been doing this for many years without this. Huh? objdump -T /usr/lib/x86_64-linux-gnu/libpq.so.5.10 ... 00021a50 gDF .text 014c Base pg_char_to_encoding 000270d0 gDF .text 002c BasePQsslStruct 00013880 gDF .text 01d2 Base PQmakeEmptyPGresult 00017900 gDF .text 0012 BasePQmblen ac20 gDF .text 02c0 Base PQencryptPasswordConn fcc0 gDF .text 00f3 BasePQresetPoll 00014790 gDF .text 00ef BasePQsendQuery 0001fc50 gDF .text 0061 BaseinitPQExpBuffer 000152a0 gDF .text 0012 Base PQsendDescribePortal ... No, Debian doesn't do symbol versioning for libpq and I don't believe it ever has. There are other libraries in Debian where the are using symbol versioning, of course, but libpq isn't one of those. Thanks! Stephen signature.asc Description: PGP signature
Re: Shared PostgreSQL libraries and symbol versioning
On 4/5/18 02:04, Pavel Raiskup wrote: > Hello, for the support of multiple versions of PostgreSQL RPM packages on > one system, we are thinking about having only one libpq.so.5 > (libecpg.so.6, libpgtype.so.3 respectively) supported and about building > (linking) all the PostgreSQL package versions against that. The pattern > would mean that we'd have to update the system-wide libraries before > adding support for new PostgreSQL major version and that the older > packages (say version =< 9.6) would be run against libs from newer PG > package (say libpq.so.5 from v10). > > Do you think it is a good idea in general? yes > As a followup thought; there are probably two major obstacles ATM > > - the DSOs' symbols are not yet versioned, and > - the build-system doesn't seem to know how to -lpq link against > external libpq.so It's not clear to me why you would need these, given that Debian has been doing this for many years without this. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Shared PostgreSQL libraries and symbol versioning
Hello, for the support of multiple versions of PostgreSQL RPM packages on one system, we are thinking about having only one libpq.so.5 (libecpg.so.6, libpgtype.so.3 respectively) supported and about building (linking) all the PostgreSQL package versions against that. The pattern would mean that we'd have to update the system-wide libraries before adding support for new PostgreSQL major version and that the older packages (say version =< 9.6) would be run against libs from newer PG package (say libpq.so.5 from v10). Do you think it is a good idea in general? Seems like pg.org [1] packaging for Debian is doing that already. As a followup thought; there are probably two major obstacles ATM - the DSOs' symbols are not yet versioned, and - the build-system doesn't seem to know how to -lpq link against external libpq.so . but technically this this is fixable; so would it be acceptable to talk about having those two points fixed? [1] https://www.postgresql.org/download/linux/debian/ Thanks, Pavel