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 ?)