Bug#839567: rake does not work with jruby

[Helmut Grohne]

On Mon, Oct 03, 2016 at 04:46:11PM -0700, tony mancill wrote:
> I agree with Helmut's suggestion that jruby should drop the Provides.
> Even if there are contexts in which jruby could act as a ruby
> interpreter, I don't think we should encourage our users to use it
> when we have ruby available.  Or put another way, if you're using
> jruby, it typically to solve a specific problem or because you have
> special considerations about your runtime environment, not because
> you're looking for a general purpose Ruby interpreter.

I think the implications of having jruby drop ruby-interpreter deserve
more thought from the ruby team.

It appears to me that jruby would just work with a fair amount of ruby
modules[1]. Yet, after dropping that provides, trying to install e.g.
jruby and ruby-text will also pull in another ruby implementation. So it
seems to me that the virtual package ruby-interpreter has actually been
used with two very different meanings which is now causing the problem:
One meaning is to provide /usr/bin/ruby and the other is a means to
execute ruby code. At the moment, jruby clearly doesn't do the former,
but still does the latter.

The Perl world has evaded this issue by not having a secondary
implementation (that is considered ready to use with existing modules).

The Python world has "solved" this issue by packaging each and every
module (in addition to extensions) for all of the interpreters. For a
module foo, we now have python-foo, python3-foo and pypy-foo (in the
worst case, e.g. -six, -wand, -pkg-resources, ...).

Please consider learning from them and - if possible - choosing a
different approach here. Consider employing a different policy that
makes the aforementioned combination feasible:

1. Every package that actually invokes ruby (as opposed to using ruby
   libraries through its own library interface) must depend on a ruby
   implementation (e.g. ruby | ruby-interpreter, or possibly an
   embedded interpreter if applicable).

2. Given that all invocation points must depend on an interpreter, ruby
   modules should not depend on a ruby-interpreter unless they require a
   particular implementation.

It seems like 1. is mostly in place already. I just note it here,
because 2. breaks badly if 1. is violated. Let me also clarify that a
module can require a particular implementation by using a ruby
extension, so the beauty mostly vanishes on the first extension in the
dependency tree. It also seems that 2. is partially in place (e.g.
ruby-power-assert, ruby-test-unit, but not ruby-text, ruby-wirble,
ruby-formatador, ...). So what I am requesting might already be policy,
but isn't fully implemented yet.

The Multi-Arch nerd over here also notes that this way allows annotating
a significant chunk of ruby modules with Multi-Arch: foreign and that
tracker.d.o will tell you where (e.g. ruby-rd).

The node people have recently started looking into Multi-Arch and
noticed that maybe having every node module depend on nodejs was not the
best approach.

Helmut

[1] Let me use the typical Perl and Python terminology here: We call
    libraries "modules" if they are source-only and we call them
    "extensions" if they produce architecture-specific artifacts such as
    shared libraries loaded into an interpreter.