Proposal to fix postgresql package maintainance nightmare

Christoph Moench-Tegeder cmt at
Tue Jul 21 19:47:30 UTC 2015

## 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"

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"

If you want to enlist me for testing/script wrangling/etc.,
just drop me an email.


Spare Space

More information about the freebsd-ports mailing list