Re: [DRE-maint] ignoring jruby

["Vincent Fourmond" <fourmond@debian.org>]

  Hello,

On Mon, Feb 25, 2008 at 7:06 AM, Lucas Nussbaum
<lucas@lucas-nussbaum.net> wrote:
>  I dont think that anybody has a clear view of all the issues that have
>  to be solved, but some of them are:
>  - where do we put third-party libs so that they are accessible by
>   ruby1.8, jruby and ruby1.9? (duplicating code for each interpreter
>   isn't sane)

  Agree... The only case where we might want to duplicate is for a
native extension, as 1.8 and 1.9 APIs are significantly different (to
the point things written for 1.8 might not compile for 1.9).

  For arch-all stuff, we could have a system of symlinks: Install the
real code in /usr/lib/ruby/extensions (for instance), and have the
files linked to /usr/lib/ruby/{1.8,1.9,jruby?} (I'm not familiar at
all with jruby). The linking could be done either at building time,
with an appropriate dh_ruby stuff, or at post-install time. The first
is a simple solution, but will cripple /usr/lib/ruby with directories
that do not seem necessary. The second is error-prone on the
developer's side (especially the ones who will write the post-inst
script).

>  - jruby doesn't support native extensions. what about software that
>   requires native extensions?

  This can be quickly dealt with: they won't work with jruby. jruby is
not in this respect a complete replacement for Ruby. We might want to
deal with that using virtual packages (ruby-runtime for all rubys, and
native extensions will need to depend on the version they are compiled
for anyway), but that does not solve the run-time problem (there is
the same problem for Java: when the package requires Sun's, you are
sure that Sun's java is installed, but you cannot assume that is has
been selected as /usr/bin/java via alternatives; you need to resort to
not-quite-beautiful shell script wrappers, see the java-wrappers
package for an idea of the mess).

>  - gems: jruby is dealt with using a "java" target in gems
>  - where do we put the bytecode?
>
>  A good starting point would be to investigate precisely what is being
>  done for java and python (python has different interpreter versions, and
>  also other interpreters, such as pysco)

  I don't know about python, but I can say that, in my opinion, the
java packages are a big mess. We have lots of different interpreters
with very different capacities, some are non-free, some are not even
officially packaged (but usable via java-package). It mostly works,
but not systematically, and no real solution for that has been
designed (and it's a good source of headache-causing bug-reports).

  Cheers,

      Vincent