From owner-freebsd-pkg@FreeBSD.ORG Fri Apr 11 16:50:18 2014 Return-Path: Delivered-To: freebsd-pkg@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88847E2F; Fri, 11 Apr 2014 16:50:18 +0000 (UTC) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5632C12A0; Fri, 11 Apr 2014 16:50:18 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id uo5so5616529pbc.18 for ; Fri, 11 Apr 2014 09:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PBwg2SCHY2p4KAOkadtCr+tQfW4xt4xu4QEUqX39Knc=; b=KWhVBqlpTNFgypsIPEjakejFa2jQ5AoUFvGF2zPFkIIQLd40jOiFjuyaswwG2ULxK/ aOh6RL8fXD7P9gwXFXU5abiyxFna9adX+J+RZsNbNUOzH/Ya7lbf4dEVMkapwcXOerOJ //ucxLZMCKwKoXgDVsgDdDrmmCPNqBFVVBKxmVYD5FTA1GCfU2FVmhAiiAunj6R/vqbk blXmgXXhFbl/GIE5D28VMkCXsbbp5CgE5H4Qw3fqnsSSxFI4ji7jHVllUo7uPbeWBKd1 nAokqCDHop4khc1pN8hzdDlEQY8mSGa7Nf4uH2tJPF5GASUoPkzFmjcYsojoIEGZ6Iys 4m6Q== X-Received: by 10.66.185.39 with SMTP id ez7mr28564829pac.134.1397235017973; Fri, 11 Apr 2014 09:50:17 -0700 (PDT) Received: from [10.10.21.90] (otra.opentable.com. [199.16.144.7]) by mx.google.com with ESMTPSA id my6sm16736143pbc.36.2014.04.11.09.50.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 09:50:13 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Installing bacula-server with PostgreSQL 9.2 From: Steven Schlansker In-Reply-To: <5347883A.5060805@FreeBSD.org> Date: Fri, 11 Apr 2014 09:50:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <413DCEA9-DE6D-4834-B9F1-6C08C7BE5F2C@likeness.com> <533CF8EB.7090403@FreeBSD.org> <6534BBBF-4D98-4FCB-A9AC-4564B0373E08@gmail.com> <5347883A.5060805@FreeBSD.org> To: Matthew Seaman X-Mailer: Apple Mail (2.1874) Cc: Dmitry Morozovsky , freebsd-pkg@freebsd.org X-BeenThere: freebsd-pkg@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Binary package management and package tools discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 16:50:18 -0000 On Apr 10, 2014, at 11:14 PM, Matthew Seaman = 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