Ruby SIG:Gems and RPM

= Ruby Gems and RPM Packaging =

, 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, 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  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  won't work, as it'll load , resulting in   rather then   to be loaded. It just so happens that  does not work well with.

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
The user's  does not include the   bin/ directories, which may be in ,  ,  , 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  or   (which should actually be   and  ), or use   while it is typically a   command.

Again, the end-user requires a midstream like Fedora to apply these fixes.

Not all gems use the same  parameters. They may, if so configured, use RPATH and statically link libraries. Gems do not necessarily compile themselves with the most optimal,  , 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, 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.