On 01/23/2013 07:28 AM, Toshio Kuratomi wrote:
On Wed, Jan 16, 2013 at 08:05:23AM -0500, Jaroslav Reznik wrote:
As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.
= Features/JRuby 1.7 =
https://fedoraproject.org/wiki/Features/JRuby_1.7
* Detailed description:
Transition to JRuby 1.7 will consist of 3 basic steps:
- Updating packages
Most of the packages that JRuby depends on are in Fedora just because of JRuby,
so they can be safely updated.
Some dependencies are shared with other packages, so they will have to be
discussed with their owners (see #Scope).
- Integration with Fedora
Normally, each Ruby implementations ships with its own copy of RubyGems
library. This is wrong because a) it's bundling, b) there is no reason
why multiple Ruby implementations wouldn't be able to share one RubyGems
library. There used to be some differencies in JRuby's copy of RubyGems,
but the JRuby upstream has been very cooperative and managed to get them
all merged into upstream RubyGems.
The integration will require changing Fedora's operating_system.rb (place
for distro-specific defaults for RubyGems). This change will result into
all Gems with binary extensions having to be recompiled, as the binary
extension placement will change. See [1] for current operating_system.rb
look and its changes from F18.
What should "/usr/bin/ruby" point to? During standard Gem packaging process,
the executable files in Gems get shebangs according to the binary that they
are packaged with (Ruby => "/usr/bin/ruby"; JRuby => "/usr/bin/jruby").
Therefore executing a Ruby "binary" runs the interpreter that was used for
building (or the hardcoded one, which is usually Ruby). Using alternatives
for "/usr/bin/ruby" doesn't seem to be a very good option, because Ruby and
JRuby are not in fact full alternatives, as they for example cannot use same
extension Gems (but it still makes sense to allow executing same binaries
with them). Also, alternatives are only switchable on admin level (we want
every developer with non-root privileges to be able to choose the
interpreter). Therefore Ruby-SIG has come up with solution of having
"/usr/bin/ruby" as a bash script (currently called rubypick) [2], that
allows user to choose the interpreter as first argument on invocation
(_mri_ or _jruby_), if such a parameter is present. Otherwise it falls
back to a default. For example invoking "ruby_binary _jruby_ --foo=bar"
in fact invokes "/usr/bin/jruby ruby_binary --foo=bar". This bash script
will be in a separate package and both Ruby and JRuby will depend on it.
Ruby-SIG knows that this feature might be controversial and we wouldn't
want it to stop us from bringing JRuby's power to Fedora (if met with a
heavy resistance). So if anyone will suggest a more suitable solution,
we'll go with it instead of this one.
- Changes in packaging
None yet. JRuby will be able to use pure Ruby Gems packaged into RPM out of
the box, but packaging of Gems with JRuby extensions is turning out to be
very complicated, so the guidelines for it will be postponed to next release
(as well as the actual packaging). Users will be still able to install Gems
with JRuby extensions, both system-wide (into /usr/local/) and into their
home directories.
[1] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_system.rb
[2] https://github.com/bkabrda/rubypick
As JRuby is setup to share pure ruby gems with ruby, I don't think this can
be approved (inlcuding the update to the jruby package to do this) until FPC
rules on whether it's okay for interpreters and languages which are not
completely compatible to share modules. FPC will hopefully have quorum
tomorrow morning to meet. If not, or if they have issues with the
guidelines, perhaps slavek and I can meet to try to figure out ways around
the issues. I'll know more after the FPC meeting time tomorrow morning.
-Toshio
Hi Toshio,
sharing Ruby gems between JRuby and rvm is supported by upstream, so why
should we disagree with upstream? They know best what they can support.
In Ruby world is JRuby used with ruby gems and other projects in Fedora
can only benefit from this behaviour.
Marcela
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
