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.
On Tue, Nov 20, 2012 at 10:19 AM, Bohuslav Kabrda bkabrda@redhat.com 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
Dne 20.11.2012 11:31, Charles Oliver Nutter napsal(a):
On Tue, Nov 20, 2012 at 10:19 AM, Bohuslav Kabrda bkabrda@redhat.com 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_system....
Vit
On Tue, Nov 20, 2012 at 11:43 AM, Vít Ondruch vondruch@redhat.com 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
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
ruby-sig@lists.fedoraproject.org