Bug#839567: rake does not work with jruby
zeha at debian.org
Tue Oct 4 20:45:27 UTC 2016
* 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. 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
- 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
> 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.
,''`. 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...
Size: 801 bytes
Desc: not available
More information about the pkg-java-maintainers