Hi Roger! Roger Leigh [2005-03-31 14:42 +0100]: > Hi Martin, > > postgresql-common wraps some of the commands in > /usr/lib/postgresql/8.0/bin/, but this does not include pg_config.
Actually I deliberately skipped pg_config since this program is only needed for building applications for PostgreSQL, not for using it. I thought that it was a good idea to explicitly specify the major version you are developing for rather than hide this in the cluster selection magic. I don't think that the particular pg_config version should be determined by /etc/postgresql-common/user_clusters or even ~/.postgresqlrc settings, this would make builds fairly indeterminate. > It's easy enough to set the PATH for configure, but if this not > necessary it would mean libpqxx could build on any packaged > postgresql version, which would be rather more flexible than > hardcoding the path. For Etch all client libraries should be built against the PostgreSQL 8 version of libpq (libpq4). libpq4 is fully compatible to libpq3 (but not the other way round, upstream removed some functions), so as long as a client app/lib builds fine with libpq4 there is no need for per-version client packages. > If there's a reason why pg_config is excluded, please just close the > bug. It's really just a "this would be nice" request, since it's > easy enough to do without! I really don't like the idea to link it against pg_wrapper. However, I am not opposed to the idea of putting a wrapper pg_config into /usr/bin which accepts a --version argument and calls the appropriate per-version pg_config. --version could default to the newest installed version. This would reduce the potential confusion/indeterminism somewhat. What do you think about this? Thanks and have a nice day, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developer http://www.debian.org
signature.asc
Description: Digital signature
