Date: Fri, 11 Apr 2014 09:50:12 -0700 From: Steven Schlansker <stevenschlansker@gmail.com> To: Matthew Seaman <matthew@FreeBSD.org> Cc: Dmitry Morozovsky <marck@rinet.ru>, freebsd-pkg@freebsd.org Subject: Re: Installing bacula-server with PostgreSQL 9.2 Message-ID: <D167F5BD-06BA-42DA-ACB5-1B63C85E0456@gmail.com> In-Reply-To: <5347883A.5060805@FreeBSD.org> References: <413DCEA9-DE6D-4834-B9F1-6C08C7BE5F2C@likeness.com> <533CF8EB.7090403@FreeBSD.org> <6534BBBF-4D98-4FCB-A9AC-4564B0373E08@gmail.com> <alpine.BSF.2.00.1404110318050.5834@woozle.rinet.ru> <5347883A.5060805@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 10, 2014, at 11:14 PM, Matthew Seaman <matthew@FreeBSD.org> = wrote: > On 11/04/2014 00:22, Dmitry Morozovsky wrote: >> On Thu, 3 Apr 2014, Steven Schlansker wrote: >>=20 >>>> The dependency on postgresql90 is "baked into" the compiled = package, and >>>> it is not possible to use that package with a different version of >>>> postgresql. Apart from anything else, any binaries are linked = against >>>> the specific ABI versions of shlibs provided by the postgresql = client >>>> package. 'pkg set -o' is not an answer in this case, >>>=20 >>> That?s very unfortunate! I would expect a binary built against = libpq 9.0 >>> to work fine when linked with libpq 9.3, but can?t say that I know = exactly >>> how good PostgreSQL is about binary compatibility. >>=20 >> The PostgreSQL team is quite straight about it: there's no promises = regarding=20 >> binary compatibility when you're changing important (in PgSQL case, = second=20 >> number) version part; hence, whenever you're drifting from N.M to = N.M+1 you're=20 >> basically forced to to dump/resore or replication. There were some = exceptions,=20 >> but usually you should be ready to set up new server and then migrate = your=20 >> database one way or another... >=20 > In fact, the Postgresql project has now declared that point releases > incrementing the minor (ie. second part) version number will not need = a > dump/restore any more. So long as you're using PostgreSQL 9.3 or = above. Fantastic! >=20 > Even so, this does not affect the library dependencies for the > postgresql binaries. The requirement there is minimally that the > library ABI version should not change. I don't know what their = policy > is -- either forwards + backwards ABI compatibility, or (like the > FreeBSD project) forwards compatibility, so a program compiled on > FreeBSD 9.0 will work on 9.1, 9.2 etc. but one compiled on 9.2 will = not > necessarily run on 9.0. =20 Replied earlier in the thread accidentally, but=20 = http://postgresql.1045698.n5.nabble.com/Details-about-libpq-cross-version-= compatibility-td5723830.html leads me to believe they are compatible both ways. > The pkg(8) system takes a conservative approach > and forces you to install exactly the same versions as used for > compilation. The new solver in 1.3 may allow some lattitude in this, > but we don't have support for dependencies on ranges of version = numbers > yet. There's a GSoC proposal to implement that which we're waiting on = a > decision about. That would be an extremely welcome feature :)=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D167F5BD-06BA-42DA-ACB5-1B63C85E0456>