Re: Wrappers don't transform @file syntax

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2020-01-17 at 11:16 GMT, Patrick Welche wrote:

> On Fri, Jan 17, 2020 at 10:36:06AM +0000, Jonathan Perkin wrote:
> > * On 2020-01-17 at 10:02 GMT, Patrick Welche wrote:
> > 
> > > On Wed, Jan 15, 2020 at 03:42:17PM +0100, Joerg Sonnenberger wrote:
> > > > Please do not use $ORIGIN. It's a constant source of issues.
> > > 
> > > My view is that the indescriminate removal of $ORIGIN at several stages
> > > of cwrappers operation is a constant source of issues.
> > 
> > It's very important to consider the context of when issues will arise
> > when debating $ORIGIN.
> > 
> > We've chosen to ensure that the issues are exposed at build time, in a
> > controlled environment, where a solution can be found that may take a
> > little longer, but will ensure that once fixed we can have confidence
> > that the binaries will function correctly and in an orderly manner
> > without being affected by changes to the environment.
> > 
> > Allowing $ORIGIN moves the exposure to run time.  In production.  When
> > something is going wrong that you're struggling to figure out, the
> > site is down, and customers are screaming at you to get things up and
> > running again.
> > 
> > I know which I'd prefer.
> 
> I'm happy with removing $ORIGIN at the end, so you don't install a binary
> containing it, but cwrappers keeps removing it no matter what stage you
> are at. Your argument just applies in the case I'm already happy with.

That's certainly an interesting idea, I just don't see it being at all
practical.  Some questions immediately come to mind:

 - How are you going to calculate exactly what the finished rpath
   should look like?  What if it differs across a package that
   contains hundreds of binaries/libraries?

 - Do all pkgsrc operating systems support editing of rpaths?

 - On macOS we would need to build everything with
   -headerpad_max_install_names to ensure the fixed rpaths have enough
   space.  Will this cause any issues?

 - What happens when the $ORIGIN at build time picks up the wrong
   library (e.g. builtin when we've configured to use pkgsrc) to
   generate some files that then can't be loaded at runtime because
   the library is different (e.g. now coming from pkgsrc).

On SunOS the ELF editor certainly has some bugs, and I need to use a
custom copy in order to produce the Rust binaries.  Obviously that's
not a fault with this idea, but just another consideration.

It would certainly be an interesting experiment, but I don't think
ultimately it would work.  Feel free to prove me wrong though ;)

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com