Re: Can we avoid chdir'ing in resolve_symlinks() ? - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Can we avoid chdir'ing in resolve_symlinks() ?
Date
Msg-id be8660d1-c191-92ad-af16-bd65f7b8e223@enterprisedb.com
Whole thread Raw
In response to Re: Can we avoid chdir'ing in resolve_symlinks() ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Can we avoid chdir'ing in resolve_symlinks() ?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 15.09.22 16:43, Tom Lane wrote:
> That seems ... a tad far-fetched, and even more to the point,
> it'd be the other package's fault not ours.  We have never promised
> that those directories point to anyplace that's not PG-specific.
> I certainly do not buy that that's a good argument for breaking
> Postgres installation setups that work today.
> 
> Also, there is nothing in that scenario that is in any way dependent
> on the use of symlinks, or even absolute paths, so I don't quite
> see the relevance to the current discussion.

Here is another variant of the same problem:

I have

$ which meson
/usr/local/bin/meson

Meson records its own path (somewhere under meson-info/ AFAICT), so it 
can re-run itself when any of the meson.build files change.  But since 
the above is a symlink, it records its own location as 
"/usr/local/Cellar/meson/0.63.1/bin/meson".  So now, whenever the meson 
package updates (even if it's just 0.63.0 -> 0.63.1), my build tree is 
broken.

To clarify, this instance is not at all the fault of any code in 
PostgreSQL.  But it's another instance where resolving symlinks just 
because we can causing problems.




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: installcheck-world concurrency issues
Next
From: Peter Eisentraut
Date:
Subject: Re: [RFC] building postgres with meson - v13