Date: Fri, 04 Dec 2015 20:57:57 +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-4pXkfW3qhZ@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 Palle Girgensohn <girgen@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pgsql@FreeBSD.org --- Comment #17 from Palle Girgensohn <girgen@FreeBSD.org> --- (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? -- 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-4pXkfW3qhZ>