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. > FPC should decide whether and how to share modules between multiple interpreters that don't have 100% compatibility with each other before the interpreters start sharing their module packages. -Toshio
Attachment:
pgpgLtDWJ1gWH.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
