Hi,
On 2022-07-15 20:38:17 +0200, Alvaro Herrera wrote:
> On 2022-Jul-15, Andy Bailey wrote:
>
> > After some investigation, I found that the value of pkglibdir (as used
> > by src/Makefile.global and various other places) was different even
> > though the ./configure invocations were identical. Eventually, I found
> > that Makefile.global was the culprit, with some sections like:
> >
> > pkglibdir = $(libdir)
> > ifeq "$(findstring pgsql, $(pkglibdir))" ""
> > ifeq "$(findstring postgres, $(pkglibdir))" ""
> > override pkglibdir := $(pkglibdir)/postgresql
> > endif
> > endif
>
> Right. See commit 984b0b4df83f and its discussion at [1]. The working
> theory (as I remember it) is that if the installation is already
> postgres-specific (because the user has made it so by having "pgsql" or
> "postgres" in the argument to --prefix), then we don't need to add
> another level of postgres-specificity to it; but otherwise we add
> "/postgresql" to the path so that the resulting files don't end up mixed
> with files installed by unrelated packages.
I think the current approach isn't great.
E.g., putting extension .so's into the same directories as "normal shared
libraries", which typically is either in the library search path via system
configuration, or in the library search path due to rpath, strikes me as quite
wrongheaded. They're not libraries that should be linked to, so they shouldn't
be in the library dir directly.
Nor do we really allow the user to opt in/out of us changing the
user-specified install locations.
Greetings,
Andres Freund