[fdo-internals] PostgreSQL out of Thirdparty

Mateusz Loskot mateusz at loskot.net
Thu Dec 6 14:53:04 EST 2007

Jason Birch wrote:
> I'm pretty sure that the Windows distribution will require a specific
> version of the Postgres DLLs, and I've seen a huge number of original
> testers running into conflicts with pq's dependancies; it's probably
> better for us to just distribute these.


There are two groups of users I can think of:

1. Regular users - use provided binaries
2. Power users - build their own FDO binaries

Option 1 requires linking with static libpq.
Unfortunately, for Windows, there is no official static library,
so we will need to build it following these instructions:


Option 2 is safest IMO and user is supposed to install PostgreSQL in any
version he likes if this is equal or higher than required
version. I don't expect any conflicts in this option.

> For ubuntu... is there any way to download just the developer libraries
> without installing Postgres?


> I thought that the -dev package had a dependancy on the main package... ?

No. The libpq-dev package does not depend on any of PostgreSQL packages:


libpq-dev bundle requires libpq runtime + additional dependencies for
SSL and cryptography support.

Summarizing, building PostgreSQL support is exactly the same problem as
for MySQL. No difference, so I assume it can be solved the same way,
using FDOPOSTGRESQL location.

> I know that the way that the FDO and MapGuide projects work
> (distributing the majority of the prerequisites) is a bit idiosyncratic
> for open source projects.  If we're going to look at this for Postgres,
> perhaps we should be considering whether we should keep any third party
> utilities in the tree that do not have local patches...  This would
> allow for better use of locally installed tools, but would also make
> per-developer setup and tracking down problems generated in an
> uncontrolled environment a lot harder.

Why not to leave issues about dependencies to maintainers of packages
for Linux distributions. Let's provide sources with well-working
building configuration + eventually FWTools-like bundle of binaries.
Many software work this way, including GDAL.

Mateusz Loskot

More information about the fdo-internals mailing list