RPM and GEMS - Unholy marriage

Bert Meerman bert.meerman at gmail.com
Mon Jun 28 07:54:38 UTC 2010


Hi everyone,

I've been following the discussion on RPM and GEMS conflict of interest. 
I found it quite interesting, and I would like to discuss some packaging 
options already present within ruby and rails.

There are three things I would like to add to Jeroen's page:
1) A valid Rails RPM package *explicit* links to gems required.
Strictly speaking, you can lazy load the gems an application needs. This 
might work, especially if you use gems that are very common (like 
Rails). Problem is, that a critical dependency is missing. You can add 
this info in the RPM spec, but I think it is better to make it mandatory 
more downstream. For RPM packaging, all you need to do is ask for the 
dependent gems.
My question: what are your thoughts on this?

2) A valid Rails RPM package must contain the version when specifying 
gems and the version must be limited.
Example:
# require 'aws/s3'
config.gem 'aws-s3', :lib => 'aws/s3', :version => '0.4.0',      #     
:source => "http://code.whytheluckystiff.net"
(see also 
http://api.rubyonrails.org/classes/Rails/Configuration.html#M002064)
This means that the module will use any version greater than 0.4.0. You 
can also specify smaller, a range or a specific number. The trick is 
this: if you do this correctly, you can use multiple gem versions on the 
same system. In theory, this must work. This is what was causing the 
issue with Lighthouse. I think you should fix the version or make it a 
range, never a 'greater than' (as in the example and with Lighthouse).
My question: what are your thoughts on this, especially the mandatory 
'limit the version number'?

3) Gems can be vendorized.
OK, this is the moment where a lot of people are going to be amazed, 
mouth open and staring at the screen for the next five minutes: you can 
make a Rails application and include the gems in it, as it where local 
code. This is called vendorization. A vendorized gem is only available 
to the application using it: it is part of the source code of that 
application and located in the /vendor directory of the application root 
(not in the normal gem directory). In fact, you can vendorize a gem and 
then even modify the code.
On one hand, if you say all gems should be vendorized, you don't have 
any version conflicts. On the other hand, I heard someone complain about 
static linking...
Personally, I disagree with the vendorization of gems. It obfuscates 
version management.
Question: does Fedore prefer (or mandatorize) a specific approach? Why?

Thanks in advance,
    Bert



More information about the ruby-sig mailing list