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.

Awesome. Thanks so much for these packages btw.

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.

It seems likely that I'm going to be using both the Java 8 and Java 11 supporting Graal bits -- at least while I work on transitioning some existing programs. I don't know how long this is going to take, but it's probably going to involve switching between them fairly frequently.

Is that kind of situation something that seems compatible with any of the alternatives you are considering for:

I can probably declare that the split packages provide graal and graal-bin, and in that case even deleting this package would work for most users, I think (though it might depend on which AUR helper they use). Another alternative would be to keep the unsplit packages and make them depend only on the java8 packages, instead of all available versions – after all, this comes closest to the status quo, which also only includes Java 8.

I asked in the Graal slack about their release strategy, and apparently they’ll continue the dual JDK strategy for the foreseeable future, so split packages indeed seems like the best approach.

I can probably declare that the split packages provide graal and graal-bin, and in that case even deleting this package would work for most users, I think (though it might depend on which AUR helper they use). Another alternative would be to keep the unsplit packages and make them depend only on the java8 packages, instead of all available versions – after all, this comes closest to the status quo, which also only includes Java 8.

Thanks for your continued work on these packages.

Overall, split packages seems nicer for the user. My understanding is that at some point the Graal stuff will move away from Java 8, but it seems likely there will be more than one Java they support at a time (the next pair being 11 and 14 perhaps).

Is it practical for the unversioned packages (graal-bin, fastr-bin, etc.) to be deprecated? May be once there are sufficient requests for packages that give all available versions of Graal creating such packages should be considered.

How does this sound to you?

So Graal 19.3.0 was released today, which ships support for both Java 8 and Java 11 (as separate downloads). fastr, truffleruby and graalpython likewise have downloads for both Java versions. How do we deal with this?

My first approach was to have the graal-bin package bundle both java8 and java11. This seems to work out reasonably well; basically, you wrap most of the package() function in a for java in 8 11 loop and adjust paths as needed. The story is a bit different for fastr (and probably the other ancillary packages), though – the tarballs for fastr don’t have a top-level common directory like the ones for Graal itself do (graalvm-ce-java8-19.3.0/), so they collide after extraction into the src/ directory (two versions of META-INF, for example). I assume this can be worked around using the noextract feature (doing the extraction with a custom target directory in prepare()), but before starting to work on that I wanted to take a break and ask for some feedback here.

The alternative would be to create split packages – graal-java8-bin, fastr-java11-bin, and so on. This seems cleaner in the long run, but on the other hand I’m not sure if there is a long run for Graal releases with multiple Java versions, or if maybe they expect to move to the latest Java version soon and only support that (updating in tandem with upstream). I’m also not sure what to do with the unversioned packages (graal-bin, fastr-bin etc.) in that event – perhaps turn them into empty packages that declare dependencies on all existing versioned packages, so that installing graal-bin gives you all available versions of Graal? And finally, I’m not terribly keen on having to update twice as many packages with each new Graal release (it’s not difficult, but all the downloading/extracting/copying/packaging does put some I/O load on my system, so it’s always a bit annoying), though it might be less work than having to fit the multiple Java versions into one package.

Any thoughts on this?

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

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.

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

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