* Helmut Grohne <hel...@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 <z...@debian.org> : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `-
signature.asc
Description: PGP signature
__ 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.