Arch Linux User Repository

Okay, the GraalVM 19.3.0 update should be done. This is now a virtual package, please explicitly install jdk8-graalvm-bin instead – or jdk11-graalvm-bin (or both). The same goes for all sibling packages (FastR, TruffleRuby, GraalPython, native-image) – the old packages have been retained and depend on the jdk8 version of the new package now, but please install the jdk8 and/or jdk11 packages explicitly, I’ll remove the old names eventually.

@lucaswerkmeister Any system with multiple binaries with the same name is in conflict. It either means this package pre-empts another or is pre-empted by another. Avoiding surprises like this is why the conflicts mechanism exists.

Declaring (and ideally preventing) conflicts is particularly important in this case because the replacements are always going to be incompatible to some degree, sometimes subtly (which can be much harder to diagnose than obvious breakage). And it's not just an issue when you explicitly install this package (which I haven't done (yet): it was pulled in by truffleruby-bin). A user can easily end up silently pre-empting (i.e. replacing) their system ruby/node/python etc. with an incompatible version without even knowing it if it's pulled in as a dependency. Good luck debugging why a core piece of functionality has stopped working in your app or on your system when you're not aware (and haven't been informed) that an app you're using which depends on java has silently replaced your system's implementation/version of node.

In the case of node and ruby, the binaries are often provided by environment managers (e.g. rvm, chruby, nvm, fnm etc.). There are two ways to enable these environments:

1) prepend them to the path (e.g. before /usr/local/bin, /usr/bin etc.)
2) append them to the path

The former is insecure: it means running a single "npm install -g", "gem install", "pip install" etc. can silently pre-empt (i.e. hijack) system binaries like ls, sudo, git etc. It might not even be malicious: just a stray (transitive) development dependency which is harmless and unnoticed when pulled into a library, but which we've now prioritized as the source of truth of what ls etc. means on our system.

• https://github.com/dthree/cash
• https://github.com/uutils/coreutils
• http://perlpowertools.com/

The latter means the environment doesn't work because it's pre-empted by this package.

> the package doesn't install any binaries into /usr/bin

I think that's the problem (or rather the solution). I think it should install into /usr/bin the way your truffleruby package does, keeping /usr/lib/jvm/java-8-graal/bin off the path altogether, e.g.:

• /usr/bin/truffleruby -> /usr/lib/jvm/java-8-graal/jre/languages/ruby/bin/truffleruby
• /usr/bin/graal-node -> /usr/lib/jvm/java-8-graal/jre/languages/js/bin/node
• /usr/bin/graal-npm -> /usr/lib/jvm/java-8-graal/jre/languages/js/bin/npm

etc.

If someone still wants the un-prefixed names, they can easily enable them explicitly by adding those bin directories to $PATH themselves.

Can you elaborate on those conflicts? I don’t see why there should be a problem – the package doesn’t install any binaries into /usr/bin (instead, it assumes that /usr/lib/jvm/default/bin is in your $PATH). On my system, I have graal-bin, nodejs, npm and ruby installed, without issue.

Some more conflicts:

rubies (e.g. ruby, jruby):

• bundle
• bundler
• gem
• irb
• rake
• rdoc
• ri
• ruby

llvm:

• lli

Thanks for maintaining this (and the other GraalVM packages)!

Unfortunately, I've had to demote this on my system (using the archlinux-java script) because some of its binaries conflict with those provided by other packages e.g. node and npm.

It would be great if these commands could be made available under different names e.g. node -> graal-node, npm -> graal-npm etc.

As it currently stands, this package conflicts with js185 (js) and any package which supplies node/npm, e.g.:

• fnm-bin
• nodejs
• nodenv
• npm
• nvm

@lucaswerkmeister: No worries! Thanks for the update and your work on this matter, very much appreciated.

I tried the graal-native-image-bin package and noticed that the last step gives us a symlink named after pkgname_, which in this case ends up being "graal-native-image". Would it be possible to have this be named "native-image" instead (or additionally)?

May be I should have posted this as a comment for graal-native-image-bin. Hope that was ok.

sogaiu: Sorry for the delay – yes, most of this has been done already :/ I just created the graal-native-image-bin package, and it’s almost a complete copy+paste of the graalpython-bin PKGBUILD, all the Graal packages use the same META-INF format. The only reason this has been delayed for so long is that I’ve been very busy and didn’t know how long this update would take. It turns out it didn’t take long at all (less than 30 minutes, I believe), I probably could’ve squeezed that in a few days earlier. Sorry :(

May be this has been done already, but FWIW, I took a look at the mentioned extra native-image jars. One of them is at:

https://github.com/oracle/graal/releases/download/vm-19.0.0/native-image-installable-svm-linux-amd64-19.0.0.jar

Unzipping the .jar file yields 2 directories: META-INF and jre.

It appears that jre is a directory tree of files necessary for native-image operation.

META-INF appears to contain at least information about the permissions for the native-image-related files that live under jre, but also information about symlinks (to be created?) for those files. These files are named "permissions" and "symlinks", respectively.

The formats seem straight-forward enough. For permissions, it appears each line represents one file path, a typical one being:

bin/native-image = rwxrwxrwx

For symlinks, it's also one line per symlink, e.g.:

bin/native-image = ../jre/bin/native-image

where what's on the left of = is a symlink to be created, and what's on the right of = is where it should point.

For both permissions and symlinks, the paths on the left of the = all appear to be relative to where graal would get installed (i.e. /usr/lib/jvm/java-8-graal)

Didn't succeed in turning up whether there are existing tools to process these files, apart from gu.

Brief examination of the output for gu --help / gu install -h didn't suggest that the tool could be told where the results should go. However, I noticed the existence of the GRAALVM_HOME environment variable elsewhere. Perhaps setting this to an appropriate value in the PKGBUILD and then invoking "gu install native-image" will yield the native-image files in an appropriate location for package building purposes.

Any thoughts?