Update TruffleRuby dependencies

[eregon]

• TruffleRuby 19.3+ uses an internal LLVM toolchain and no longer depends on LLVM.
• The full dependencies are listed at https://github.com/oracle/truffleruby/blob/master/README.md#dependencies
• Previous versions of TruffleRuby detect if LLVM is missing and print a nice error message, so it is not an issue to remove the dependency for older versions.

@postmodern @havenwood Could you merge this soon as it might prevent macOS Cataline users to install TruffleRuby? (https://github.com/oracle/truffleruby/issues/1820 for details)

[eregon]

Thanks for the quick review and merge :)

[eregon]

The dependencies are going to change again, for instance libxml2 won't be needed in TruffleRuby 20.0, and openssl-devel might no longer be a dependency in the future.

@postmodern @havenwood I'm thinking dependencies should be part of ruby-versions, and also be per version so we can easily change them for each release if needed. Any thoughts on that?

We could have something like: truffleruby/dnf which contains lines like 19.3.0: zlib-devel openssl-devel make gcc libxml2. And truffleruby/apt similarly, etc.

[havenwood]

Should we only maintain bleeding edge dependencies, or also deps for older versions? Deps can be tied to Ruby or OS version, but they also feel like a totally different thing than Ruby versions metadata.

Would this be maybe better in a new ruby-dependencies repo, or do you think it's a good fit for ruby-versions?

[postmodern]

As a general rule we should support the stable version(s) of Rubies and OS/distros, as those are officially supported by their upstream maintainers. Tracking the dependencies for all Rubies, all Ruby versions, all package managers, and all OS/distro releases would be a path to madness; and duplicate data.

@eregon as a compromise, once < 20.0 becomes unsupported we can drop those dependencies.

[eregon]

all OS/distro releases

Yeah that one would be a path to madness, and is only very rarely needed (openssl vs openssl-compat was one case for old distros).

I think the rest would still be reasonable (see my example, it's only 2 levels per Ruby implementation), but I get your point.

For the point of view of a Ruby implementer, it would make most sense if the dependencies are associated to a given release, because that's at those points dependencies can change, and it does change as we see here (MRI also changed dependencies a few times).

Also having it in ruby-versions means users could get updated dependencies easily (and therefore a better user experience, if e.g., a new dependency was added), in comparison to ruby-install which is more complicated to update (needs a release, uninstall/reinstall, etc).

An an example of a highly problematic case, see #360 / https://github.com/oracle/truffleruby/issues/1820#issuecomment-557949636 where installing truffleruby fails because the depencies are outdated (and Homebrew removed the llvm@4 formula). @postmodern To mitigate that one, could you make a new release of ruby-install?

[postmodern]

Storing dependencies in ruby-versions is out of scope; ruby-versions tracks releases and release artifacts. A better long-term solution might be to standardize on a metadata format for specifying dependencies, and include it with ruby releases themselves. Until then, ruby-install either has to pick generic package names for maximum compatibility, or we have to introduce messy logic to pick the right package name depending on the ruby version, package manager, and platform.

[eregon]

@postmodern Could you do a release of ruby-install? People are still hitting this issue: https://github.com/oracle/truffleruby/issues/2008

[eregon]

Yet another user hitting this, could you make a 0.7.1 release with this fix (or current master) soon?

[postmodern]

Prepping a 0.7.1 release. Will be offline until evening when it cools down; currently too hot to continue running the workstation.

[postmodern]

0.7.1 has finally been released!

[eregon]

Thank you!