Note to all package users: I’ve decided to stop maintaining GraalVM packages on the AUR. If anyone else wants to pick them up, feel free to contact me if you have questions, but don’t expect a ton of enthusiasm from me, nor especially fast responses. I’ll leave some potentially useful information below.
With the packaging changes since the 23.1.0 release(s) of GraalVM (corresponding to OpenJDK 21.0.0), I think it no longer makes sense to have the jdk version in the package name. There should be one jdk-graalvm-bin package, with a pkgver matching the OpenJDK version (currently 21.0.0); and there should be one package for each other component (TruffleRuby, GraalPy, etc.), with the pkgver taken from the year-based GraalVM version (currently 23.1.0), but with “jdk-less” names like truffleruby-bin or graalpy-bin.
The jdk-graalvm-bin packaging should now be based substantially on the OpenJDK one. I’ve uploaded a provisional PKGBUILD and related files here: https://gist.github.com/lucaswerkmeister/c4a8f5f1f5bcd46852d1c028c01ae2f2
The other packages will have to change substantially from their older versions, as the distributed artifacts have changed. Previously, upstream distributed the other components as JAR files, which included META-INF/symlink and META-INF/permissions files that contained information that can’t always be represented in the JAR format; a big part of the PKGBUILD of each package then reconstructed the information from those files. This is now obsolete, as the components are distributed as gzipped tarballs. However, there is a new big problem. Previously, the components had dependencies on each other (e.g. GraalJS depended on separate components for ICU4J and Regex components), which I modeled as separate AUR packages. Now, each tarball seems to be complete and self-contained, which is achieved by just duplicating the dependencies; for instance, a modules/polyglot.jar file is found in the tarballs for Graal-NodeJS, GraalJS, TruffleRuby, and probably many others, and there are no separate downloads for components like ICU4J and Regex at all anymore as far as I can tell. If the PKGBUILD just copies all the source files into the pkgdir, then the packages will all conflict with one another. I don’t know a great solution to this; I think the Arch/AUR packager might just have to extract shared base packages with the duplicated files manually (trying to figure out which files make sense in which package). I started a PKGBUILD for graal-nodejs-bin here, but it doesn’t solve the duplicated files problem: https://gist.github.com/lucaswerkmeister/1fc04809144403ae46478c61ac40a4ea
Finally, I have to caution you that working with Oracle is just not fun. Years ago I was foolish enough to actually send them a pull request for a simple bug, which required going through a laborious CLA process; they then proceeded to steal my patch and commit it without any attribution, as permitted by the CLA. Do not sign their CLA (the “OCA”, Oracle Contributors Agreement). After that, I of course mostly limited myself to filing issues, but they’re generally very slow to respond to either issues or pull requests. (You definitely don’t want to wait for them to fix an issue before you publish a package update; just work around it in whatever way you can, and hope that you can eventually remove the workaround.) They also don’t learn from their mistakes at all, having managed to not include license files in their releases no fewer than five times.
Pinned Comments
lucaswerkmeister commented on 2023-09-30 16:19 (UTC)
Note to all package users: I’ve decided to stop maintaining GraalVM packages on the AUR. If anyone else wants to pick them up, feel free to contact me if you have questions, but don’t expect a ton of enthusiasm from me, nor especially fast responses. I’ll leave some potentially useful information below.
With the packaging changes since the 23.1.0 release(s) of GraalVM (corresponding to OpenJDK 21.0.0), I think it no longer makes sense to have the jdk version in the package name. There should be one
jdk-graalvm-binpackage, with a pkgver matching the OpenJDK version (currently 21.0.0); and there should be one package for each other component (TruffleRuby, GraalPy, etc.), with the pkgver taken from the year-based GraalVM version (currently 23.1.0), but with “jdk-less” names liketruffleruby-binorgraalpy-bin.The
jdk-graalvm-binpackaging should now be based substantially on the OpenJDK one. I’ve uploaded a provisional PKGBUILD and related files here: https://gist.github.com/lucaswerkmeister/c4a8f5f1f5bcd46852d1c028c01ae2f2The other packages will have to change substantially from their older versions, as the distributed artifacts have changed. Previously, upstream distributed the other components as JAR files, which included META-INF/symlink and META-INF/permissions files that contained information that can’t always be represented in the JAR format; a big part of the PKGBUILD of each package then reconstructed the information from those files. This is now obsolete, as the components are distributed as gzipped tarballs. However, there is a new big problem. Previously, the components had dependencies on each other (e.g. GraalJS depended on separate components for ICU4J and Regex components), which I modeled as separate AUR packages. Now, each tarball seems to be complete and self-contained, which is achieved by just duplicating the dependencies; for instance, a
modules/polyglot.jarfile is found in the tarballs for Graal-NodeJS, GraalJS, TruffleRuby, and probably many others, and there are no separate downloads for components like ICU4J and Regex at all anymore as far as I can tell. If the PKGBUILD just copies all the source files into the pkgdir, then the packages will all conflict with one another. I don’t know a great solution to this; I think the Arch/AUR packager might just have to extract shared base packages with the duplicated files manually (trying to figure out which files make sense in which package). I started a PKGBUILD for graal-nodejs-bin here, but it doesn’t solve the duplicated files problem: https://gist.github.com/lucaswerkmeister/1fc04809144403ae46478c61ac40a4eaFinally, I have to caution you that working with Oracle is just not fun. Years ago I was foolish enough to actually send them a pull request for a simple bug, which required going through a laborious CLA process; they then proceeded to steal my patch and commit it without any attribution, as permitted by the CLA. Do not sign their CLA (the “OCA”, Oracle Contributors Agreement). After that, I of course mostly limited myself to filing issues, but they’re generally very slow to respond to either issues or pull requests. (You definitely don’t want to wait for them to fix an issue before you publish a package update; just work around it in whatever way you can, and hope that you can eventually remove the workaround.) They also don’t learn from their mistakes at all, having managed to not include license files in their releases no fewer than five times.