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.
- 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)
- 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.
Vít
[1]
http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups
[2] http://rpm.org/ticket/857
_______________________________________________
ruby-sig mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
