English Portuguese (Brazil)
*JRuby Gems*:
Although Fedora has fully functioning JRuby
integrated with system RubyGems,
we have decided to not include the JRuby specific packaging guidelines here,
as they need some more work.
They will appear here as soon as we feel that we've got everything covered properly.
You can contact us on
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org/[Ruby-SIG mailing list]
in case of any questions
about the prepared JRuby packaging guidelines.
There are three basic categories of ruby packages: <<RubyGems>>, <<Non-Gem Packages,non-gem Ruby packages>>, and <<Applications,applications written in Ruby>>. These guidelines contain sections common to all of these as well as sections which apply to each one individually. Be sure to read all the guidelines relevant to the type of ruby package you are building.
Ruby Compatibility
Each Ruby package MUST indicate it depends on a Ruby interpreter (this does not apply to <<RubyGems>>). Use `ruby(release)` virtual requirement to achieve that:
Requires: ruby(release)
If the package requires Ruby of certain version(s), make the requirement versioned like this:
Requires: ruby(release) >= 1.9.1
*Alternate interpreters*:
Alternate Ruby interpreters (currently JRuby)
also `Provide: ruby(release)`.
This implies, that pure RubyGems packages (these are shared among interpreters) SHOULD NOT have `Requires: ruby` or `Requires: jruby` to have their dependencies satisfied by any of these interpreters.
*Over specified ruby(release) versioning*:
Please note that if the `ruby(release)` version requirement is too specific,
it might cause an unexpected interpreter to be drawn in.
E.g. `ruby(release) = 1.8` will require JRuby package,
since it is the only package that provides it.
Different Interpreters Compatibility
Most of the pure Ruby packages will work on all Ruby interpreters. There are however cases when the packages use interpreter-specific functions (like `fork()`) and won't run on other interpreters (JRuby). In this case, the package SHOULD require that interpreter. For example, a package that uses `fork` SHOULD explicitly specify `Requires: ruby`. In case of such package, packager SHOULD file a bug to ask upstream to provide support for other interpreter(s). This SHOULD be documented in specfile.
Shebang lines
On Fedora, `/usr/bin/ruby` is implemented via https://github.com/bkabrda/rubypick[Rubypick]. Rubypick is a tool similar to RVM or rbenv. It allows choosing interpreter to execute Ruby script. Rubypick routes anything executed via `/usr/bin/ruby` to `/usr/bin/ruby-mri` or `/usr/bin/jruby`. By default, it runs MRI (Matz's Ruby Implementation), but user can explicitly specify the interpreter by using `+_mri_+` or `+_jruby_+` as a first parameter. For example:
ruby _jruby_ jruby_script.rb
gem _mri_ install foo
rails _jruby_ s
Using the `RUBYPICK` environment variable can achieve the same results. The environment variable can be used to set one interpreter as the global default:
export RUBYPICK=_jruby_
ruby jruby_script.rb # Will use jruby
gem install foo # Will also use jruby
Ruby executables that are known to only run on one Ruby implementation SHOULD use that specific implementation in their shebang (`+#!/usr/bin/ruby-mri+` or `+#!/usr/bin/jruby+`) to ensure that they run using that implementation. All other code SHOULD use `+#!/usr/bin/ruby+`.
Naming Guidelines
Packages that contain Ruby Gems MUST be called `+rubygem-%{gem_name}+`.
The name of a ruby extension/library package MUST start with the interpreter it is built for (ruby, jruby, etc.) and then the `UPSTREAM` name. For example: `ruby-UPSTREAM`. If the upstream name `UPSTREAM` contains `ruby`, that SHOULD be dropped from the name. For example, the SQLite database driver for ruby is called `sqlite3-ruby`. The corresponding Fedora package SHOULD be called `ruby-sqlite3`, and not `ruby-sqlite3-ruby`.