[fdo-internals] PostgreSQL out of Thirdparty
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.
More information about the fdo-internals