Ruby Gems and RPM Packaging
gem, Ruby's way of managing pluggable Ruby modules, and RPM, Fedora's way of managing all packages (including Ruby's pluggable modules), are two different ways to achieve the same thing -Or are they?
"Gems are Parallel Installable"
With gem, you can have more then one version of a gem available on your system. For example:
$ gem install rack-1.0.0 $ gem install rack-1.1.0
Will install and have available both versions of the rack gem. This is seen as an advantage by many people, but does not result in a state that is desirable for Fedora. Given the rack example, it turns out rails-2.3.5 won't work, as it'll load rack ~> 1.0.0, resulting in rack-1.1.0 rather then rack-1.0.0 to be loaded. It just so happens that rails-2.3.5 does not work well with rack-1.1.0.
Here's a list of options:
- Patch rails to specifically require and load the correct version of rack,
- Patch rack-1.1.0 to work for rails (and any other package, fwiw),
- Vendor the correct version of rack in the rails package,
- ...
You can see how some if not all of these options require a midstream distributor in between the gem repositories and the end-user system.
Packages that Require Ruby Gems
Some packages (for example, Alexandria) require a bunch of Ruby Gems, but do not distribute a Ruby Gem themselves. Being distributed through an RPM package, the required Ruby gems still need to end up on the end-user system. Vendoring the Ruby gem's code is not allowed for many, many just reasons. It has to be distributed through RPM.
The $PATH
The user's $PATH does not include the $GEMPATH bin/ directories, which may be in ~/.gem/ruby/<version>/bin, %{ruby_vendorlib}/bin/, %{ruby_sitelib}/bin/, etc., etc. A user would need elevated privileges to install any bin commands in the appropriate, standard $PATH directories, or is required to modify the $PATH environment variable.
Additionally, gems do not necessarily use the correct bin or sbin directory. Some will install their binary commands in /bin/ or /sbin/ (which should actually be %{_bindir} and %{_sbindir}), or use %{_bindir} while it is typically a %{_sbindir} command.
Again, the end-user requires a midstream like Fedora to apply these fixes.
./configure
Not all gems use the same ./configure parameters. They may, if so configured, use RPATH and statically link libraries. Gems do not necessarily compile themselves with the most optimal CC_FLAGS, CPP_FLAGS, etc. Gems may, by themselves, not necessarily be able to find the appropriate library (e.g. a (legacy) compat library should be used and not the latest, for example stdc++).
Let's remember that the focus of gems is towards multi-platform, multi-purpose distribution of Ruby pluggable modules.
Library dependencies
When installing a gem through $ gem install, none of the module's non-gem dependencies are pulled in. The gem may require one or the other system library to compile, or even just Ruby header files.