Re: Helmut Grohne > The other way is moving this file into an architecture-dependent > package. Given its reliance on pg_config, why is it not part of > libpq-dev in the first place? Is moving it there an option? Do you > happen to know what would break if the file were moved?
pg_config used to be in postgresql-server-dev-NN, but since PG extension autopkgtests need $(shell pg_config --pgxs), I moved pg_config and pgxs.mk into postgresql-client-NN so the tests don't pull in postgresql-server-dev-NN with its clang dependencies. Also, it seemed to be a good move in general to have pg_config available in the default install on PG servers. It can't go into libpq-dev because libpq-dev is independent from the PG major version. (There *is* a pg_config in libpq-dev, but it gets dpkg-diverted away by postgresql-common, i.e. on server installs.) Perhaps we could throw a 3rd copy of pg_config into postgresql-server-dev-NN (which isn't MA) and prefer that over the one from postgresql-client-NN? How much does cross-compiling PG things work if you fix the compiler flag bit? My last info was that there were more bits missing. If this is the last one, I'll gladly work on a fix. Christoph
