On Thursday, September 22, 2011 09:29:37 AM Vít Ondruch wrote:
Dne 21.9.2011 17:45, Mo Morsi napsal(a):
> On 09/21/2011 07:46 AM, Vít Ondruch wrote:
>> Dne 21.9.2011 13:43, Vít Ondruch napsal(a):
>>> * Support of gems for MRI and JRuby.
>>> - Is it possible to share RubyGems?
>>> - Is it possible to share gems?
> Its difficult since the gems themselves depend on the rubygems package
> which depends on MRI. Perhaps if we can break this dependency somehow
> this would be more feasible.
> Just thought of a random idea, would the rubygems package be able to
> _not_ depend on a specific package, rather depend a 'ruby-interpreter'
> capability, which then would be provided by both the MRI and JRuby
> packages? Then MRI / JRuby could be swapped in / out and any gem that
> depends on a specific interpreter could have the MRI/JRuby dependency
> there instead having it in rubygems.
> Granted this would make it more difficult to install both MRI and JRuby
> at the same time on the same system, though it may be feasible, just
> haven't thought this one through.
RubyGems has to be subpackage of Ruby, because they could be upgraded
later separately, if needed. I am big fan of moving RubyGems out of MRI
and use one RubyGems package for both MRI and JRuby and it is doable IMO.
However I am not sure how to support gems which are bit different
between MRI and JRuby versions. Nokogiri would be one example. I am
still missing some support in RPM for this, something like:
Requires: nokogiri-mri if mri.installed
Requires: nokogiri-jruby if jruby.installed
With the shift to Ruby 1.9.x.. I am preparing to get the OpenNebula packaging
effort underway. had meetings with developers, I'm drawing up a wiki.
Assuming all these rubygems I'm *about* to submit work with Ruby 1.9.x I
strongly suggest a compat package...
ruby-sig mailing list