Re: faster testing with symlink installs

On Wed, Feb 28, 2018 at 9:34 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> Except ... this doesn't actually work. find_my_exec() resolves symlinks
> to find the actual program installation, and so for example the
> installed initdb will look for postgres in src/bin/initdb/. I would
> like to revert this behavior, because it seems to do more harm than
> good. The original commit message indicates that this would allow
> symlinking a program to somewhere outside of the installation tree and
> still allow it to work and find its friends. But that could just as
> well be done with a shell script.
>
> Reverting this behavior would also allow Homebrew-like installations to
> work better. The actual installation is in a versioned directory like
> /usr/local/Cellar/postgresql/10.1/... but symlinked to
> /usr/local/opt/postgresql/. But because of the symlink resolution,
> calling /usr/local/opt/postgresql/bin/pg_config returns paths under
> Cellar, which then causes breakage of software built against that path
> on postgresql upgrades the change the version number.

My initial gut feeling is that changing this would hurt more people
than it would help. It seems entirely reasonable to install
PostgreSQL in, say, /opt/local/postgresql, and then symlink psql and
pg_ctl into /opt/local/bin or /usr/bin or wherever you like to find
your binaries. I don't think we want to break that. It's true that
it will work if you symlink everything, as in your Homebrew example,
but you might not. TBH I find that Homebrew example pretty odd. I
would understand installing each major release in a version directory,
but putting every point release in a different versioned directory
seems like a bad plan.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company