RubyGems changes to accomodate multiple ruby implementations

[Bohuslav Kabrda]

Hi all,
as I'm working towards getting JRuby packaged, I started playing around with RubyGems
and the default operating_system.rb, that modifies the behaviour on Fedora.
Since the ultimate plan is to have shared RubyGems for all implementations, every one of
these implementations will need its own extension directories. So far, we had just MRI and
its extensions went under /usr/lib[64]/gems/exts. I'd like to propose that we change
this to /usr/lib[64]/gems/ruby for MRI, /usr/share/gems/jruby for jruby (since java
extensions aren't platform specific) and when rubinius comes, we can place its
extensions under /usr/lib[64]/gems/rubinius.
The customized operating_system.rb (and the whole rubygems) are at [1]. I would appreciate
any comments/thoughts on this.
There is a small regression hidden in this: The gems installed with "sudo gem
install" currently place their extensions under /usr/local/lib64/gems/exts, which
would also change to /usr/local/lib64/gems/ruby, causing these gems to need reinstallation
if my changes are applied, but I don't think this should keep us from doing this
transition.

Thoughts?
Thanks,
Slavek.

-- 
Regards,
Bohuslav "Slavek" Kabrda.

[1] https://github.com/bkabrda/jruby.spec/tree/master/rubygems

[Charles Oliver Nutter]

On Tue, Nov 20, 2012 at 10:19 AM, Bohuslav Kabrda <bkabrda(a)redhat.com&gt; wrote:
>  There is a small regression hidden in this: The gems installed with
> "sudo gem install" currently place their extensions under
> /usr/local/lib64/gems/exts, which would also change to /usr/local/lib64/gems/ruby, causing
> these gems to need reinstallation if my changes are applied, but I don't think this
> should keep us from doing this transition. 
I don't think anything can keep you from doing this transition, since
exts will never be portable across 32/64 or MRI/Rubinius or
1.8/1.9/2.0 C API...it kinda just has to happen if there's going to be
support for multiple installed Rubies on a single system.

I did not see you mention different locations for 1.8 versus 1.9
versus 2.0 exts...they are also not generally portable.

- Charlie

[Vít Ondruch]

Dne 20.11.2012 11:31, Charles Oliver Nutter napsal(a):
>  On Tue, Nov 20, 2012 at 10:19 AM, Bohuslav Kabrda
> <bkabrda(a)redhat.com&gt; wrote:
> > There is a small regression hidden in this: The gems installed with "sudo gem
> install" currently place their extensions under /usr/local/lib64/gems/exts, which
> would also change to /usr/local/lib64/gems/ruby, causing these gems to need reinstallation
> if my changes are applied, but I don't think this should keep us from doing this
> transition.
>  I don't think anything can keep you from doing this transition, since
>  exts will never be portable across 32/64 or MRI/Rubinius or
>  1.8/1.9/2.0 C API...it kinda just has to happen if there's going to be
>  support for multiple installed Rubies on a single system.
>
>  I did not see you mention different locations for 1.8 versus 1.9
>  versus 2.0 exts...they are also not generally portable. 
We do not plan to support multiple MRI versions. So there is no need for 
that.

However, this might or might not come into play for Rubinius. But if 
that will be needed, the gems should go into 
/usr/lib[64]/gems/rubinius/{1.8,1.9,2.0} probably. In that case the line 
[1] will need some additional tweaks. But the important is that the rest 
of gems will stay untouched.


[1] 
https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_syst...


Vit

[Charles Oliver Nutter]

On Tue, Nov 20, 2012 at 11:43 AM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote:
>  Dne 20.11.2012 11:31, Charles Oliver Nutter napsal(a):
> > I did not see you mention different locations for 1.8 versus 1.9
> > versus 2.0 exts...they are also not generally portable.
>
>
>  We do not plan to support multiple MRI versions. So there is no need for
>  that.
>
>  However, this might or might not come into play for Rubinius. But if that
>  will be needed, the gems should go into
>  /usr/lib[64]/gems/rubinius/{1.8,1.9,2.0} probably. In that case the line [1]
>  will need some additional tweaks. But the important is that the rest of gems
>  will stay untouched. 
In the Rubinius case, the 2.0 release (still in development) will
support both 1.8 mode and 1.9 mode (unless they change their minds)
and possibly 2.0 mode. All of these have incompatible ABIs so they
would need to be installed in different locations.

JRuby's Java ext ABI/API does not change from 1.8 to 1.9 mode, but may
change over time. We already have to deal with that with upstream gem
authors today.

- Charlie

[Mo Morsi]

On 11/20/2012 04:19 AM, Bohuslav Kabrda wrote:
>  There is a small regression hidden in this: The gems installed with
> "sudo gem install" currently place their extensions under
> /usr/local/lib64/gems/exts, which would also change to /usr/local/lib64/gems/ruby, causing
> these gems to need reinstallation if my changes are applied, but I don't think this
> should keep us from doing this transition.
>  
Ya, can't see there being a problem so long as we make it known to the
larger Fedora community (and perhaps publish this change in the docs /
release notes)

  -Mo