ruby rails, gem packages

[John Taber]

On 10/25/2009 02:22 PM, Jeroen van Meeuwen wrote:
> 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.
>    

I agree with your reasons, it is just so much work to keep up - it is 
like running a parallel rubyforge or gemcutter.  Also,  what happens 
when a user wants to use a gem not supported by Fedora ? then the user 
must use gem install anyway (unless Fedora wants to package them all ?)