Re: Shared PostgreSQL libraries and symbol versioning - Mailing list pgsql-hackers

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
>