Date: Sat, 05 Dec 2015 02:21:44 +0000 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 Message-ID: <bug-201796-13-1TiRE6JxJO@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-201796-13@https.bugs.freebsd.org/bugzilla/> References: <bug-201796-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201796 --- Comment #18 from Chris Hutchinson <portmaster@bsdforge.com> --- (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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-201796-13-1TiRE6JxJO>