Hi Christoph, On Mon, Oct 14, 2024 at 10:09:56PM +0200, Christoph Berg wrote: > 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.
I note that postgresql-server-dev-NN was not M-A:foreign. So the move that you describe here is what caused the bug report at hand (while at the same time improving other aspects). > 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.) Thanks for clarifying. > 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? At this time, I'm not sure what the solution is, but I am pretty sure that pg_config should not be part of any package that is marked Multi-Arch: foreign. In the perl world, we were faced with a problem that looks vaguely related to me. What we ended up doing there was adding a virtual package perl-xs-dev. Then, we gradually switched over all source packages building perl architecture-dependent perl extension modules to build-depend on this. The take-away here is that the functionality required for building extensions is now captured in a separate name and allows reorganizing the perl source without incurring subsequent changes to all perl extensions. The addition of a virtual package (that may become real later) also means that we can make the transition soft for downstreams: Add the provides to postgresql-client now, transition rdeps, then reorganize without disrupting many consumers. > 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. As far as I understand it, pg_config is very architecture-dependent. It isn't just one aspect and we'd be done. To make matters worse, pg_config also is an ELF executable. Hence we have a choice between producing results for the wrong architecture (status quo) and not being able to run it at all. My main approach for improving cross building of postgres reverse dependencies has been patching out uses of pg_config in favour of pkg-config (where feasible), but pg_config --pgxs doesn't work at similar ease. I have no solution to offer here. So as unfortunate as this may be, pg_config technically poses a violation of Multi-Arch: foreign. It should not reside in a package marked M-A:foreign and fixing this bug will likely not improve cross building in any practical way (except maybe for making it fail faster). A vague option I see on the horizon would be changing the pgxs.mk Makefile to prefer use of pkgconf over using pg_config. Then, a user may set the PKG_CONFIG variable to determine the host architecture and then include pgxs.mk picking up values for the desired architecture. However, the present libpq.pc does not answer all the questions that pg_config answers now (e.g. --mandir), so we're looking at a deeper rabbit hole. Helmut
