Обсуждение: 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
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
Greetings, * Peter Eisentraut (peter.eisentraut@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 ... 0000000000021a50 g DF .text 000000000000014c Base pg_char_to_encoding 00000000000270d0 g DF .text 000000000000002c Base PQsslStruct 0000000000013880 g DF .text 00000000000001d2 Base PQmakeEmptyPGresult 0000000000017900 g DF .text 0000000000000012 Base PQmblen 000000000000ac20 g DF .text 00000000000002c0 Base PQencryptPasswordConn 000000000000fcc0 g DF .text 00000000000000f3 Base PQresetPoll 0000000000014790 g DF .text 00000000000000ef Base PQsendQuery 000000000001fc50 g DF .text 0000000000000061 Base initPQExpBuffer 00000000000152a0 g DF .text 0000000000000012 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
Вложения
Stephen Frost <sfrost@snowman.net> writes:
> * Peter Eisentraut (peter.eisentraut@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
On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: > > * Peter Eisentraut (peter.eisentraut@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 >
Вложения
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 <sfrost@snowman.net> writes: > > > * Peter Eisentraut (peter.eisentraut@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 > > > >
Greetings, * Pavel Raiskup (praiskup@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 <sfrost@snowman.net> writes: > > > > * Peter Eisentraut (peter.eisentraut@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 concern that Tom raised, as well as consider if there's additional work that will need to be done upstream for it. Debian played around with simply slapping versioned symbols on whole libraries before and ran into some trouble, as I recall, so I suspect there's more to be said here than just "well, we'll just version everything every time." What happens when a new release is cut and all of the symbols have been changed to be newer- will all the existing packages have to be rebuilt to reference those newer symbols and would all therefore depend on the newer libpq? Or will we need to keep the symbol version for existing symbols the same while managing newer symbols with newer symbol versions (ala what glibc does, with no small amount of effort required to do so...). > > 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. Instead of just pushing on it, I'd suggest trying to address the concern raised by Tom, and the other ones which I mention. Thanks! Stephen
Вложения
Thanks Stephen, On Wednesday, May 23, 2018 1:13:08 PM CEST Stephen Frost wrote: > Greetings, > > * Pavel Raiskup (praiskup@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 <sfrost@snowman.net> writes: > > > > > * Peter Eisentraut (peter.eisentraut@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 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. Thanks, interesting! Can you post some link I could read? How can I read what symbols are provided by Debian's libpq package? > > > 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 concern that > Tom raised, as well as consider if there's additional work that will > need to be done upstream for it. Agreed, but since we don't add new symbols within one minor version, it's as easy as doing: + <NEW_SYMBOL> <ID> <PG_MAJOR_VERSION> instead of: + <NEW_SYMBOL> <ID> > Debian played around with simply slapping versioned symbols on whole > libraries before and ran into some trouble, as I recall, so I suspect > there's more to be said here than just "well, we'll just version > everything every time." What happens when a new release is cut and all > of the symbols have been changed to be newer- will all the existing > packages have to be rebuilt to reference those newer symbols and would > all therefore depend on the newer libpq? > Or will we need to keep the symbol version for existing symbols the same > while managing newer symbols with newer symbol versions (ala what glibc > does, with no small amount of effort required to do so...). What I'd like to propose is the latter, "newer symbols => newer version" approach. It in turn (by default) means that under newer version is provided superset of symbols from previous version. > > > 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. > > Instead of just pushing on it, I'd suggest trying to address the concern > raised by Tom, and the other ones which I mention. 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. Note that I'd really like to hear the answers above, how Debian's depsolver deals with sets of library symbols; maybe that's something we could think about in RPM, too. Thanks! Pavel [1] https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html
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 (praiskup@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 <sfrost@snowman.net> writes: > > > > > > * Peter Eisentraut (peter.eisentraut@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 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) ... Pavel > > > > 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 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. > > Thanks, interesting! Can you post some link I could read? How can I read > what symbols are provided by Debian's libpq package? > > > > > 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 concern that > > Tom raised, as well as consider if there's additional work that will > > need to be done upstream for it. > > Agreed, but since we don't add new symbols within one minor version, it's > as easy as doing: > > + <NEW_SYMBOL> <ID> <PG_MAJOR_VERSION> > > instead of: > > + <NEW_SYMBOL> <ID> > > > Debian played around with simply slapping versioned symbols on whole > > libraries before and ran into some trouble, as I recall, so I suspect > > there's more to be said here than just "well, we'll just version > > everything every time." What happens when a new release is cut and all > > of the symbols have been changed to be newer- will all the existing > > packages have to be rebuilt to reference those newer symbols and would > > all therefore depend on the newer libpq? > > Or will we need to keep the symbol version for existing symbols the same > > while managing newer symbols with newer symbol versions (ala what glibc > > does, with no small amount of effort required to do so...). > > What I'd like to propose is the latter, "newer symbols => newer version" > approach. It in turn (by default) means that under newer version is > provided superset of symbols from previous version. > > > > > 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. > > > > Instead of just pushing on it, I'd suggest trying to address the concern > > raised by Tom, and the other ones which I mention. > > 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. > > Note that I'd really like to hear the answers above, how Debian's > depsolver deals with sets of library symbols; maybe that's something we > could think about in RPM, too. > > Thanks! > Pavel > > [1] https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html >
Re: Pavel Raiskup 2018-05-24 <101829257.NN0XsvVvxK@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
Hi Christoph, On Thursday, May 24, 2018 12:08:16 PM CEST Christoph Berg wrote: > Re: Pavel Raiskup 2018-05-24 <101829257.NN0XsvVvxK@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. Thanks for that sum-up! > > 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), Well, it's possible benefit, yes. But changing symbols without bumping SONAME would be really Linux only, not very easy upstream change and it's not what I ask for. At least as long as we claim libpq has a backward compatible API/ABI, and if some incompatible change happens it is generally acceptable to bump the soname version. The semantic in versioning I'd like to have is the "Solaris OS" way, if you read Ulrich's dsohowto.pdf, chapter "3.3 ABI Versioning". In a sense that newly added symbol means the API get's newer version. By looking at the ELF, you can see what ABI version you need. Also from upstream POV, symbol versions bring the benefit that once we do the SONAME bump one day, and the server process gets two versions of the libpq library loaded accidentally (through transitive dependencies, e.g. through PostgreSQL server modules) - without symbol versions there's a danger that plugins will be executed against incompatible ABIs, it might lead to disaster. > 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. But if added symbol means new ABI version, then you can bake the ABI version into Depends (Requires) and you are sure that if you have package which provides this ABI, you are fine. The "package name" or "package version" providing the "library ABI" is then an orthogonal thing you don't have to care about. I started speaking about symbol versioning, but it was a bad idea - I should have start with ABI/API versioning. /me is changing subject. > > 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? We automatically generate Requires:/Provides like 'lib<NAME>.so<VERSION>(ABI_VERSION)', e.g.: $ rpm -q --provides xz-libs | grep so.5 liblzma.so.5()(64bit) liblzma.so.5(XZ_5.0)(64bit) liblzma.so.5(XZ_5.2)(64bit) liblzma.so.5 liblzma.so.5(XZ_5.0) liblzma.so.5(XZ_5.2) > > > 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. Yes. It's not for free, but still an acceptable/necessary thing :-(. I'd really love to deal with this upstream first. Pavel > Christoph >