From owner-freebsd-pkg@FreeBSD.ORG Fri Apr 11 16:49:07 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 3567FCE7; Fri, 11 Apr 2014 16:49:07 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (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 037DA128C; Fri, 11 Apr 2014 16:49:06 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id y10so5432965pdj.8 for ; Fri, 11 Apr 2014 09:49:06 -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=s0c5XXg4jDzAQYjp4BizeeOD04EgVUJVl7r4HhDIimY=; b=JaRa7OE65RZEHFgXr3hBKhwNy+zC7WAEEh2E6GKG638UhS2060yuOg43Str349Tpaz USNa4cz85uov/WBWMPspGiWQwBNOiigceneLJxssQD8XhjpCiS+UmaYzNF2trf7xu37n hrhMLgR5gGpupkx/CqoXSFgMEI4zThm67SUvVfivcfEbEOJf99PdUg0se9+IbTMutG9K L/jEBGc6+m1EWDYn91cQ4RMkwvs+MH9/AL5Nqj5NfhBDaieOpa/SacBrtT27Bj55p/W9 l3DhKYQsX8Lz5FF5WZLi3JcRe9NCvft7ISLEDhg0O39mixHFojqiPQib2beF0C8In3Em MrwQ== X-Received: by 10.68.229.68 with SMTP id so4mr28434643pbc.110.1397234946589; Fri, 11 Apr 2014 09:49:06 -0700 (PDT) Received: from [10.10.21.90] (otra.opentable.com. [199.16.144.7]) by mx.google.com with ESMTPSA id vb7sm16761828pbc.13.2014.04.11.09.49.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Apr 2014 09:49:03 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 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: Date: Fri, 11 Apr 2014 09:49:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1676FF51-DC56-4F8B-917E-CBB625C981FC@gmail.com> References: <413DCEA9-DE6D-4834-B9F1-6C08C7BE5F2C@likeness.com> <533CF8EB.7090403@FreeBSD.org> <6534BBBF-4D98-4FCB-A9AC-4564B0373E08@gmail.com> To: Dmitry Morozovsky X-Mailer: Apple Mail (2.1874) Cc: Matthew Seaman , 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:49:07 -0000 On Apr 10, 2014, at 4:22 PM, 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=85 Hi Dmitry, You are totally correct for the binary representation of the *database = on disk*. This is something I know and already had to deal with when we upgraded = 9.1 -> 9.2. However this thread is entirely about a end-user program that *links* = against libpq which is totally different. And the replies from Heikki and Tom = in this thread: = http://postgresql.1045698.n5.nabble.com/Details-about-libpq-cross-version-= compatibility-td5723830.html make it sound like it should certainly be source-compatible and = almost-certainly binary compatible. Which means this sounds like a deficiency in =91pkg=92= itself. Thanks, Steven