----- Original Message -----
Dne 29.11.2012 09:43, Bohuslav Kabrda napsal(a):
> Hi all,
> as F19 is slowly approaching, I thought it'd be great to finalize
> the stuff about JRuby/Ruby integration with Fedora. Here are the
> changes and additions around JRuby, that I suggest:
> * Global changes
> - As already mentioned in [1], change the default
> operating_system.rb, the current version is at [2]. The question
> here is, whether to use versioned directories for extensions. In
> my opinion we should do that, as users installing Gems under
> /usr/local may want to install them for different version of JRuby
> (Rubinius in the future). This change will cost us nothing and
> will make sure that we can utilize this in the future.
We do not support more version of MRI nor JRuby nor we support
anything
else. The only exception would be if the interpreter support
compatibility modes for different Ruby versions => I am against
versioning in /usr/local unless explicitly needed.
I meant the interpreters that support multiple compatible modes. So e.g. Rubinius users
may want to install extensions under /usr/local for both ruby-1.8 and ruby-1.9 compat
modes (once we have Rubinius). It is true, that for now this shouldn't be needed (as
Charles has mentioned, JRuby extensions should work with both compat modes). I do not
consider this to be a "must have" feature, so if you'll shout at me for a
long enough time, I'll just give it up ;)
> - Add additional macros to macros.rubygems, see [3] (if the
macros
> names seem confusing, see the section about packaging gems for
> JRuby below).
The jruby/java suffixes are confusing. We should go only with one of
them. I am inclined to -jruby (not sure why -java was chosen by
RubyGems
or as a platform)
Yep, I agree that they may seem confusing. We may use "_jruby" (I'm assuming
that you're talking about the macro names, not the actual directories/gemspecs/etc),
but we have to find a good way of distinguishing between the extdir that contains
"-java" suffix and extdir that doesn't contain it (for JRuby-only gems).
So how about
1) All the JRuby macros have "_jruby" suffix.
2) The ext dir for JRuby gems that don't contain "-java" in their name, the
macro would be called sth. like %{gem_extdir_jruby_pure}.
> - Two connected problems: 1) RPM generates auto provides from
> shebangs, e.g. #!/usr/bin/ruby will automatically require ruby
> package; 2) How to run programs with #!/usr/bin/ruby shebangs
> under JRuby?
> -- We've discussed this situation with Vit and we came up with an
> interesting proposal for solution. There will be a package
> (probably with just one file) /usr/bin/ruby. This will be a bash
> script, that will take all given parameters and pass them to the
> proper interpreter (/usr/bin/ruby-mri or /usr/bin/jruby). There
> will be a default choice (MRI, I guess) and the switching will be
> done by passing _jruby_ (possibly also containing version) or
> _mri_ as the first parameter. If e.g. /usr/bin/ruby-mri is not
> found, the script will automatically try /usr/bin/jruby and if
> that is not present either, it will print out that user needs to
> install a Ruby runtime.
Please note that RubyGems are using similar approach already. E.g.
you
can run `rake _0.8.7_` to execute your rake task using explicitly
defined version of Rake. So we would just extend this idea a bit
further.
> -- This way, the automatically generated requires will point to the
> package containing /usr/bin/ruby and not the actual ruby package,
> therefore leaving it up to user which Ruby runtime he wants to
> install.
> -- Also, every executable file with this shebang can be run with
> _mri_ or _jruby_ parameter: "rspec _mri_" vs. "rspec _jruby_",
the
> same for gem, irb and anything that has the proper shebang.
I would be interested if anybody know about any possible
showstoppers.
>
> * Changes to packaging
> - Platform independent packages mustn't R: ruby, unless there is a
> specific reason to do so.
> - Packages with MRI binary extensions will have to R: and BR: ruby
> explictly, not just ruby(abi), as that will also be provided by
> JRuby.
> - Packages meant only for JRuby will have to R: and BR: jruby
> explictly (same reason). These will use the %gem_extdir_jruby
> macro.
> - Packages with extensions for both Ruby and JRuby (let's consider
> rubygem-json, example of converted specfile is at [4]):
> -- MRI extension will probably stay in the core package
> (rubygem-json).
> -- There will be a subpackage with -java suffix (because the naming
> scheme on
rubygems.org gives e.g. json-1.7.5-java). The subpackage
> will contain it's own .gemspec and because all the directory/file
> names contain the "-java" string, it will use the %gem_*_java
> macros.
> -- The -java subpackage will contain the JRuby extension under
> %gem_extdir_java and it's platform independent part will be a
> symlink to platform independent part of its MRI counterpart (e.g.
> /usr/share/gems/gems/json-1.7.5-java ->
> /usr/share/gems/gems/json-1.7.5).
> -- The disadvantage of this approach is, that the core package
> (rubygem-json) will be a dependency of rubygem-json-java,
> therefore forcing MRI to be installed.
>
> or
>
> -- The rubygem-json-java package could be independent of
> rubygem-json (e.g. everything same as above, except it will
> actually contain the platform independent part). This would in
> fact not require MRI ruby to be installed, but I'm not sure of the
> consequences of this.
> -- A big question is, how to handle provides (applies to both
> cases). RPM cannot say "I'm fine with rubygem-json or
> rubygem-json-java", so the -json package will probably have to
> Provides: rubygem(json-java) and users will have to install these
> manually, if they want to use JRuby.
Taking rubygem-json as an example, I'd love to see:
rubygem-json - contains platform independent code
rubygem-json-mri - subpackage containing MRI binary extension
rubygem-json-jruby - subpackage containing JRuby extension
Unfortunately, there is probably no way how to install proper
subpackages, unless we would go with comps [1] for example. But I
opened
ticket on RPM [2] requesting support for this.
Yep, that would be exactly what we need and we should really push for this. But I
don't see this solution coming for F19, so we will have to make a temporary decision
for the time being. Thinking of the two above alternatives further, I would prefer the
first one, because the Requires: rubygem(json) will pull rubygem-json in anyway, so the
second solution doesn't in fact bring benefits in terms of RPM dependencies.
Thanks for your thoughts, Vit. I hope the others will comment as well :)
--
Regards,
Bohuslav "Slavek" Kabrda.