Proposal to fix postgresql package maintainance nightmare

joris dedieu joris.dedieu at
Fri Jul 24 15:37:21 UTC 2015

2015-07-21 21:47 GMT+02:00 Christoph Moench-Tegeder <cmt at>:
> ## Baptiste Daroussin (bapt at
>> 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 (
> 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="..."

Is not that an other problem ? Maybe we need a generic mechanism to
manage instances (think mysql, tomcat, apache ...) ? At least a common
syntax, to avoid something like the [check|config][test|check] issue

> If you want to enlist me for testing/script wrangling/etc.,
> just drop me an email.
> Regards,
> Christoph
> --
> Spare Space
> _______________________________________________
> freebsd-ports at mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at"

More information about the freebsd-ports mailing list