Re: CVS commit: pkgsrc/pkgtools/cwrappers/files/bin

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

* On 2021-11-08 at 00:47 GMT, Christos Zoulas wrote:

> I would like to understand the objections for $ORIGIN compared to 
> setting LD_LIBRARY_PATH which is in my opinion strictly worse.

Packages built using pkgsrc are only ever designed to be installed into 
the specific location chosen either at bootstrap time or by the native 
pkg_install (i.e. /usr/pkg).  They will never support relocation.

One of the core features of pkgsrc is correctness.  We have a large 
number of checks that go into ensuring that the binaries we build are 
robust in the face of a potentially hostile environment into which they 
are ultimately placed.  That means verifying that they only ever link 
against the exact libraries we specify that they require, and we have a 
large and complicated system called buildlink which enforces these 
constraints, as well as a number of checks under mk/check that verify 
the binaries we've built are robust.

Without these checks, the chances of distributing packages that work on 
the build host but fail in the user environment increase dramatically, 
and ultimately leads to a terrible user experience of pkgsrc.

As someone who has been distributing millions of packages to users over 
the past few years built using pkgsrc, I'd say that what we have is 
actually the bare minimum of what's required, and in many cases I've 
gone further than the defaults to ensure that the packages we ship are 
as reliable as possible across different user installs (e.g. adding 
CHECK_SHLIBS_TOXIC support, additional CHECK_WRKREF directories, etc.)

Allowing $ORIGIN, or any other path that bypasses many of our strict 
checks and throws a proverbial YOLO bomb into the runtime environment is 
simply not acceptable.  There's no need for it, and it goes against 
everything that we stand for.

To me the comparison to LD_LIBRARY_PATH is very clear.  LD_LIBRARY_PATH 
is specifically used at _build_ time, and only when we need to 
temporarily run binaries from the build area that link against other 
artefacts inside the build area that have not yet been installed.  Yes,
LD_LIBRARY_PATH is not ideal, but we are only ever using it during a 
build, and never at runtime where it can affect installed binaries.

$ORIGIN on the other hand is a _runtime_ setting, and results in 
distribution of binaries that can have wildly different and 
unpredictable behaviour depending on the user environment.

> The java build which uses LD_LIBRARY_PATH for bootstrap
> works only by accident, since it forces LD_LIBRARY_PATH on the 
> bootstrap jdk which is not appropriate
> (for example it does not work when you try to bootstrap using a linux 
> jdk, and it requires all the jdk binaries
> to be wrapped.

Ok, so just fix that?  If you have a look at the openjdk packages I use 
for SmartOS, e.g.:

  https://github.com/joyent/pkgsrc-joyent/tree/master/openjdk11

you can see that I do not have that LD_LIBRARY_PATH setting, and instead 
have correctly patched each call site to ensure it pulls in the correct 
libraries.  It would be trivial for someone to make similar changes to 
the NetBSD package.

> The cwrappers code is a mess; there is a lot of code duplication, and 
> it is not clear (to me) how and where are options processed. Using 
> $ORIGIN simplifies the build and allows the jdk to work from any 
> directory without using LD_LIBRARY_PATH which is the whole point.
> I committed the change to isabs() separately to demonstrate how small 
> is the change to allow $ORIGIN.

Please don't make unreviewed, unapproved, and dangerous changes to 
critical parts of the pkgsrc infrastructure.  If there's a bug in a 
pkgsrc package, just say so and we can fix it.  There's no need for an 
atomic bomb if all that's required to fix the problem is a pair of 
tweezers.

The only time $ORIGIN is acceptable is when producing a bootstrap kit 
that will itself be used to build a final pkgsrc package.  In these 
situations it's absolutely required because we do not know in advance 
where the bootstrap kit will be unpacked to, and you can find examples 
of how to produce such kits here:

  https://github.com/joyent/pkgsrc-joyent/blob/master/openjdk11/Makefile#L140-L177
  https://github.com/joyent/pkgsrc/blob/trunk/lang/rust/Makefile#L510-L586

Regards,

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