Re: Michael Paquier > > I was confusing that with this: The problem that led to the pg_config > > patch years ago was that we have a /usr/bin/pg_config in > > (non-major-version-dependant) libpq-dev, and > > /usr/lib/postgresql/NN/bin/pg_config in the individual > > postgresql-server-dev-NN packages, and iirc the /usr/bin version > > didn't particularly like the other binaries being in > > /usr/lib/postgresql/NN/bin/. > > > > I guess it's time to revisit that problem now and see if it can be > > solved more pretty today on our side. > > If you can solve that, my take is that it could make things nicer in > the long-run for some of the TAP test facilities. Still, I'll try to > look at a solution for this thread that does not interact badly with > what you are doing, and I am going to grab your patch when testing > things.
tl;dr: This is no longer an issue. Since build-time testing broke again about two weeks ago due to Debian's pg_config patch, I revisited the situation and found that the patch is in fact no longer necessary to support pg_config in /usr/bin: To support cross-compilation against libpq, some years ago I had already replaced /usr/bin/pg_config (in libpq-dev) with a perl script that collects path info at build time and outputs them statically at run time [1]. The "real" /usr/lib/postgresql/15/bin/pg_config (in postgresql-server-dev-15) is still the C version, now unpatched with full relocatability support. [1] https://salsa.debian.org/postgresql/postgresql-common/-/blob/master/server/postgresql.mk#L189-194 https://salsa.debian.org/postgresql/postgresql-common/-/blob/master/server/pg_config.pl Christoph
