From owner-freebsd-ports-bugs@freebsd.org Sat Dec 5 02:21:45 2015 Return-Path: Delivered-To: freebsd-ports-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A6CAA3FE94 for ; Sat, 5 Dec 2015 02:21:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 240C31DA8 for ; Sat, 5 Dec 2015 02:21:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tB52Li0C047969 for ; Sat, 5 Dec 2015 02:21:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 201796] Mk/bsd.default-versions.mk: Set PostgreSQL 9.4 as default Date: Sat, 05 Dec 2015 02:21:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, needs-qa, patch, patch-ready X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: portmaster@bsdforge.com X-Bugzilla-Status: Open X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: girgen@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback- exp-run+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 02:21:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201796 --- Comment #18 from Chris Hutchinson --- (In reply to Palle Girgensohn from comment #17) > (In reply to Chris Hutchinson from comment #16) > > Hi Chris et al, > > (adding pgsql@ to the cc list) > > The problem is also that pg_upgrade requires *both* postgres binaries to be > intalled. > > > The goal, as I see it, is more than just suppporting pg_upgrade. It is to > allow multiple server versions installed side by side (need by some for test > frameworks, for example), and also, more importantly, to simplify > dependencies for packages depending on libpq. > > Today, FreeBSD install client and server for the selected version only, and > it conflicts with other versions. This means all packages depending on libpq > are only built for the one default version of postgresql, and changing the > default is a tedious Q&A process. And as users upgrade, everything that > depends on libpq needs to be updated as well, and this can be a lot. And > also, we have the problem with pg_upgrade which need both the old and the > new postgres (server) binaries. > > > I'm hacking right now to test two similar approaches. > > 1. Allow multiple -server versions installed side-by-side, but only allow > one -client (like now), and let client always default to the latest released > version. [1] > > 2. Allow multiple -server and -client versions side-by-side, and have a > separate postgresql-libpq package. > > > Most port that sets USES=pgsql just require libpq, it would always depend on > the same port (postgresql-client in the first alternative, postgresql-lib in > the second). Packages for client applications would be built and could be > used with any version of the postgresql server. > > > The second approach is quite similar to what Debian does today. There are > some scripts i Debian that are interesing (pg_lsclusters, pg_ctlcluster, > pg_upgradecluster), but for now, I think they are out of scope, just to keep > the effort at a reasonable level. Maybe later... This approach would require > a meta port to symlink the client binaries to $PREFIX/bin. > > The first approach is a bit less complex, which is nice. We could even do > without a meta port, or at least a simpler one for chosing the preferred > server version. We need to move some stuff from the client to the server > port, like includes and man pages, since they really are not part of the > client. > > I'm leaning towards the first alternative at the moment. > > Palle > > > [1] client stuff in postgresql is backwards compatible except perhaps for > some very strange old things that is rarely used. We would keep the old > -client ports around in case one of these odd cases comes up. Also, new > versions would be installable this way. "latest released version" could be > x.y.1, i.e. we could wait for the first patch release, why not? Thanks for such an informative reply, Palle! Approach #1 was the way I understood would be the initial way, going forward, from the mailing list thread. My response, above, was an effort to help initiate the process in some way -- any way. :) I don't feature my being able to manage the whole task. But liked the whole concept, in the email thread, and was hoping to help. Feel free to assign me a task, if you think I can help. :) Thanks again, Palle. --Chris -- You are receiving this mail because: You are on the CC list for the bug.