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. 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  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. __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.