Date: Tue, 21 Jul 2015 21:47:25 +0200 From: Christoph Moench-Tegeder <cmt@burggraben.net> To: freebsd-ports@freebsd.org Subject: Re: Proposal to fix postgresql package maintainance nightmare Message-ID: <20150721194725.GB1457@elch.exwg.net> In-Reply-To: <20150721094627.GD21594@ivaldir.etoilebsd.net> References: <20150721094627.GD21594@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
## Baptiste Daroussin (bapt@FreeBSD.org): > We do manage a bunch of postgresql servers on FreeBSD, and I really find the > current model of packages postgresql is a nightmare on FreeBSD. Not that much worse than in some other environments :) Comparing all the PostgreSQL packaging models, I like the debian model best (PostgreSQL is my day job, so I can claim some experience here). > Having one single postgresql-client package always on the latest stable version > (backward compability being very good) providing the client cli tools and the > libraries (those libraries will be used for everything in the ports tree > needing to talk to postgresql) As others already noted, using a psql (command line client) with a version different from the respective server has it's limitations (it works in general, but some of the meta commands may fail). On the other hand, the ABI of libpq is stable enough for all the supported versions of psql (and other clients). So you'd need one package with libpq alone, and another one with psql and the other client utils (http://www.postgresql.org/docs/9.4/static/reference-client.html is the list). The server itself would be the another package. The libpq package can always be built from the latest release of PostgreSQL. An additional "postgresql-{client,server}-meta" package would provide symlinks from ${LOCALBASE}/bin/<postgresbinary> to ${PREFIX}/bin/<postgresbinary> (PREFIX being the PREFIX for the selected PostgreSQL package, postgresbinary all the binaries PostgreSQL installs). For applications using PostgreSQL, the USES=pgsql logic has to point configure and it's equivalents to the right pg_config, and all well behaved applications should find the right libraries etc. > That way everything talk to pgsql will only depend on one postgresql-client > packages that will smoothly be upgraded to newer versions. Using the schema outlined above, the "normal" PostgreSQL-using application will only have to depend on the libpq package, which is version-agnostic. Only those applications which really need psql will have to depend on the (versioned) posggresql-client package, or even better, the client-meta package (that way, changes of the default postgresql version will not require dependency-wrangling throughout the tree). > Any opinion on that change? Any idea one how to make the upgrade path as > transparent as possible for current setup? (beside of course adding an UPDATING > entry) Using the meta-packages (which could just pick up the previously set default version), the upgrade path should be completely transparent for most cases. Another thing I've been thinking about is the ability to have multiple PostgreSQL clusters on one machine. Currently there's only the one "postgresql_data" variable in rc.conf. It shouldn't be that hard to have something like postgresql94_clusters="default stage dev" postgresql94_default_data="..." postgresql94_stage_data="..." Depending on the rc script handling (one script to rule them all vs. each PostgreSQL has it's own script), we might even do something line postgresql_clusters="9.4:default 9.5:testing" postgresql_default_data="..." postgresql_testing_data="..." If you want to enlist me for testing/script wrangling/etc., just drop me an email. Regards, Christoph -- Spare Space
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150721194725.GB1457>