Re: $ORIGIN in RPATH suppression

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Thu, 2 Jan 2025 09:25:01 +0000
> From: Jonathan Perkin <jperkin%pkgsrc.org@localhost>
> 
> * On 2025-01-01 at 14:53 GMT, Havard Eidnes wrote:
> 
> >So...  What is the *actual* *defensible* reason we continue to
> >disallow the use of $ORIGIN in RPATH in pkgsrc?  And if no such
> >defensible reason can be put forward, can we please stop
> >suppressing this?  Pretty, please?
> 
> There have been many reasons explained many times previously on the list 
> (we don't support relocatable packages, $ORIGIN introduces security and 
> reliability concerns, etc), but if you want at least a couple of hard 
> reasons why as well, then it would break both check-shlibs and REQUIRES,
> as well as wiz' new pkg_add checks.

It would be nice if this were written down somewhere easily findable
that we could refer to like on the pkgsrc wiki.

One reason that is _not_ relevant any longer is the historic
unreliability of $ORIGIN for programs executed with execve(2).  The
absolute path that gets used is a little quirky (see
https://mail-index.netbsd.org/tech-userlevel/2024/12/16/msg014624.html
for details) but the silly failure mode involving vnode namecache
pressure was eliminated back in 2017 and no longer applies in netbsd-9
or netbsd-10 except to programs executed with fexecve(2).

And, setting aside whether $ORIGIN is right or wrong, perhaps we could
safely use $ORIGIN during the build, and teach check-shlibs and
REQUIRES and pkg_add and whatever to find and reject $ORIGIN if it is
found to be baked into the final product.