> On Nov 8, 2021, at 4:36 AM, Jonathan Perkin <jperkin%joyent.com@localhost> wrote: > > * 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. This is orthogonal to the discussion. The bootstrap jdk is a prime example of a package which if built correctly, will be relocatable. In fact we need it to be relocatable in order to use it for bootstrap since we are copying it to a different location that the one it was built. > > 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. I am not suggesting that we change every package to use $ORIGIN. Only the jdk. > 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. It just creates a mess. Packages like the jdk that are designed to use $ORIGIN should not be modified like that. Again, During LD_LIBRARY_PATH during the build for the jdk only works by chance, since during the build it starts using newly linked artifacts try to load libraries from the bootstrap path (because of LD_LIBRARY_PATH), so if the new libraries are providing symbols the old ones don't have, or sizes of structures have changed, the new binaries die. This is the same reason why you can't bootstrap from linux. The new netbsd binaries attempt to load the bootstrap linux libraries. > $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. It is a compile time setting that behaves predictably during runtime. Please explain why $ORIGIN is unpredictable. $ORIGIN uses the path of the executable to deduce a path for the libraries. >> 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. Then it does not work for bootstrap and it is too complicated. The fact that we have to patch the jdk in many places should be a strong hint that we are are doing something wrong. Anyway, as you have seen, nobody has attempted to build anything > jdk11 for years just because the whole process is such an unholy mess. In fact I don't think that anyone will be able to without following my approach or suffering for days and creating an abomination. >> 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. I was very temped to rewrite that whole mess which appears to be written by a first year undergrad student who just learned c. It is a probably a thousand lines longer than it has to be. It also looks like someone kept finding corner cases that were not handled and instead of re-thinking the whole approach kept adding special case code. Nobody can maintain such code. I would recommend that the maintainers fix it properly. > 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 We are trying to fit a round peg in a square hole because of the religious belief that $ORIGIN is bad. This is not the TV show Stargate. Respectfully, christos
Attachment:
signature.asc
Description: Message signed with OpenPGP