Bug#839567: rake does not work with jruby

[Christian Hofstaedtler]

* Helmut Grohne <helmut at subdivi.de> [161004 06:59]:
> 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.

This is true; right now, being a "ruby-interpreter" implies:

 1. actually have /usr/bin/ruby and related bins.
 2. support all native extensions. **

> [..]

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

Which is a lot of work. Previously, ruby had version-specific packages
(not different from having interpreter-specific packages).

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

We thought through a number of options before moving to the current
state. IIRC some of these were:

  - All libs get an interpreter/version-specific package and
    dependencies are always on a specific package. The virtual
    ruby-interpreter package can go away.
    This is a lot of busy work: introducing and removing binary
    packages all the time, when there is no actual code change in
    *most* packages.

  - Do not support more than version/implementation. We are
    doing this today. The existence of ruby-interpreter is
    an internal artifact.

  - All libs support all interpreters. We are doing this during
    transitions (e.g. 2.1->2.2). This is why ruby-interpreter
    exists today ***.

[..]

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

Well, s/should not/do not need to/ in our case. I'd agree it would
be nicer if that would be done in all packages, but it is not a
priority.

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

Noted. A number of dependency cycles would also go away, I imagine.


** Plus, ruby-interpreter serves as an escape hatch for
bootstrapping rubyX.Y on new archs.
*** This is done using code in dh_ruby.


Best,
-- 
 ,''`.  Christian Hofstaedtler <zeha at debian.org>
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20161004/b05d8da9/attachment-0001.sig>