Package Details: graal-bin 19.2.0.1-1

Git Clone URL: https://aur.archlinux.org/graal-bin.git (read-only)
Package Base: graal-bin
Description: Universal virtual machine for running applications written in a variety of languages (JVM-based, LLVM-based, or other)
Upstream URL: https://www.graalvm.org/
Licenses: custom
Conflicts: graal
Provides: graal, java-environment=8, java-runtime=8
Submitter: lucaswerkmeister
Maintainer: lucaswerkmeister
Last Packager: lucaswerkmeister
Votes: 18
Popularity: 1.169562
First Submitted: 2018-05-02 22:30
Last Updated: 2019-09-13 19:10

Dependencies (3)

Required by (1000)

Sources (1)

Latest Comments

1 2 3 Next › Last »

chocolateboy commented on 2019-09-13 19:52

> do you have references supporting this interpretation?

AFAICT, there's no de jure when it comes to these fields (the fact that your interpretation cites a wiki page ought to be a hint). There is only de facto, and I've provided several examples of how these fields are used in practice.

> Then why are you even asking for a conflicts field in the first place?

I'm not asking for a conflicts field. I'm politely requesting non-conflicting names, e.g. graal-node, graal-npm etc. Is there a particular reason not to do this? AFAICT, it would take less time/effort than this discussion :-)

> If you don’t have a system node installed, there’s nothing for graal-bin to conflict with anyways.

I've already explained how and why the conflict exists. No-one who installs truffleruby expects it to install node and npm, and doing so without warning is a de facto conflict.

lucaswerkmeister commented on 2019-09-13 19:21

As I understand it, package X conflicts with package Y if X provides the same functionality as Y

Then why even have provides and conflicts as separate fields? This interpretation makes no sense to me.

More importantly, though, you didn’t answer my question: do you have references supporting this interpretation?

As mentioned, there are two ways to enable an environment, either by prepending or appending it to $PATH.

That’s a simplification – what really matters is the order of $PATH elements, and it’s not just about prepending or appending: it’s also important when you append something to it. I think the (portion of) $PATH that you need is this:

  • /usr/local/bin
  • /usr/bin
  • ~/.fnm/current/bin
  • /usr/lib/jvm/default/bin

Since you want to use the node binary from fnm, you need to place it ahead of JVM in your $PATH. How exactly you achieve this will depend on how your shell is initialized.

I don't have a system node installed (via nodejs).

Then why are you even asking for a conflicts field in the first place? If you don’t have a system node installed, there’s nothing for graal-bin to conflict with anyways.

chocolateboy commented on 2019-09-10 01:19

> Do you have any references supporting your interpretation of conflicts?

As I understand it, package X conflicts with package Y if X provides the same functionality as Y, e.g. ssmtp provides smtp-forwarder and therefore conflicts with any other packages which provide smtp-forwarder, e.g. msmtp, nullmailer, postfix etc.

This package provides a node binary, so it provides and conflicts with nodejs (cf. nodejs-0.12).

> I think the solution to your problem is to manage your $PATH correctly

It's precisely because I'm managing my $PATH correctly that this is an issue. Let me give you a concrete example (there are others since this package installs so many unexpected binaries).

I use fnm to manage my node versions (this also applies to other environment managers, e.g. nvm). I don't have a system node installed (via nodejs). As mentioned, there are two ways to enable an environment, either by prepending or appending it to $PATH.

Here is (a portion of) my $PATH:

  • /usr/local/bin
  • /usr/bin
  • /usr/lib/jvm/default/bin
  • ~/.fnm/current/bin

1) If I prepend fnm to the path (which it tries to do by default), it allows binaries bundled by NPM packages to pre-empt system binaries. This is a bad idea for the same reason that prepending "." to the path is a bad idea.

2) If I append fnm, as I do currently, its node is pre-empted by the version provided by this package.

The conflict doesn't necessarily matter in the case of an smtp-forwarder since they all implement the same core interface (e.g. cat mail | sendmail), so one can be substituted for the other. It matters here since this package's node is incompatible/incomplete and will likely remain so indefinitely.

If the names were prefixed (with /usr/lib/jvm/java-8-graal/bin restricted to JRE binaries), the problem would go away and I could safely use both. And, as I say, anyone who wanted un-prefixed names could easily enable them by adding the /usr/lib/jvm/java-8-graal/jre/languages/*/bin directories to their $PATH.

lucaswerkmeister commented on 2019-09-09 23:47

@chocolateboy my understanding of the conflicts field is that packages only conflict if they actually can’t be installed at the same time, because they provide the same file. This is the case for the example given in the ArchWiki: netbeans and netbeans-javase both include /usr/bin/netbeans. This understanding is also supported by the PKGBUILD(5) manpage, which says:

An array of packages that will conflict with this package (i.e. they cannot both be installed at the same time).

Do you have any references supporting your interpretation of conflicts?

I think the solution to your problem is to manage your $PATH correctly, and ensure that directories are appended to it in the right order (or reorder the entries at some later point in your shell initialization sequence, if the initial appends are out of your control).

chocolateboy commented on 2019-09-09 23:07

@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.

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.

lucaswerkmeister commented on 2019-09-09 21:03

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.

chocolateboy commented on 2019-09-09 13:27

Some more conflicts:

rubies (e.g. ruby, jruby):

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

llvm:

  • lli

chocolateboy commented on 2019-09-09 03:00

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.:

sogaiu commented on 2019-05-30 16:01

@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.

lucaswerkmeister commented on 2019-05-30 11:01

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 :(