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
