ruby rails, gem packages

[Jeroen van Meeuwen]

On 10/25/2009 07:28 PM, John Taber wrote:
> most tutorials recommend installing rails and other packages using gem -
> and since they change often, I'm not too sure what the value is of
> trying to supply Fedora packages for the gems.  In fact using the Fedora
> gem packages might just mess things up especially between 1.8.6 and
> 1.9.1 because of the different way each handles gems.
>
>   From our standpoint, we've always just loaded ruby via the Fedora
> packages and then everything via gems.  This has been both easy and has
> worked well.  I think it is better to forget making Fedora packages of
> the gems and concentrate on packages for the various Ruby language
> versions - just my $.02
>

The way I understand what you are saying is that you don't see what 
added value creating RPM packages of gems has.  I'm going to try and 
explain a few of the arguments here;

1) gems come from several sources. Several pieces of documentation will 
just tell you to gem install foo --source http://from/somewhere. There 
is no easier way to see the available gems then through a single 
distribution channel, and trust the single distribution channel rather 
then to trust all various sources for gems.

2) if a gem is installed, the system does not know about it's 
capabilities. Other products, in particular those from another upstream, 
cannot require capabilities it can't find through RPM provides.

3) in some cases, gem update will break your system. In some cases, we 
might even find that a yum update breaks your system, but at least we 
have a mechanism in place to roll back the changes.

4) gems come from several upstreams with their own release policy. In 
order to figure out what does, and what does not work together, a 
distribution uses it's own package management. This is how a distributor 
like the Fedora Project makes sure (or at least attempts to) one part of 
the system works with the other parts of the system.

5) a "gem install" uses (might use) suboptimal compilation flags, not 
getting the most out of a (binary compiled) gem (or ruby module).

6) a "gem uninstall" does not necessarily uninstall the gems that 
require it, or the gems it pulled in. For example, activeresource 2.3.4 
might be installed while your rails is still at 2.3.2.

7) building RPM packages from gems also allows us to patch them. While 
it is often sufficient to upgrade, upgrades might bring API changes with 
them. Hence, being able to ship patches is essential for a distributor 
to form some kind of platform that is stable (rather then subject to all 
kinds of API changes).

8) Building RPM packages allows us to show you, the consumer, what is 
going to be in the next generation of Enterprise Linux. Presumably, when 
EL-6 comes out, we branch off all the Ruby gems that we have now, and 
freeze the entire lot. This (thus) also gives you the chance to:

8a) Develop your application towards a long term sustainable for your 
consumers to enjoy;
8b) Develop your application without too much hassle in updating and 
upgrading gems (possibly changing APIs)
8c) Have your consumers do a yum install your-application
8d) Prevents you from vendoring libraries (which is a very, very bad 
thing, and puts more load on consumers and distributors)

I hope at least some of these arguments appeal to you, although you 
probably do not attach as much value to each of them like I do.

The system that we have right now at least gives you options; use the 
ruby gem RPM packages, or just use gem. I can only recommend what I 
think is best.

Kind regards,

Jeroen van Meeuwen
-kanarip