On Mon, 2013-02-04 at 18:01 -0600, Les Mikesell wrote:
> On Mon, Feb 4, 2013 at 5:36 PM, Craig White <craig.white@xxxxxxxxxx> wrote:
> >
> >
> > And lastly, Ruby is an ecosystem far beyond the base language. It has a 'gem' package management system which again is cross platform and even when you try to package ruby in rpm's, there's no way an RH or EPEL will keep up with updates.
> >
>
> I guess I still don't understand why you think that is a good thing.
> If the developers didn't get it right the first dozen times, why do
> you think the next update will be better? That is, if EPEL can't keep
> up, why would anyone want to? If you don't have the QA that a
> packager does it means you have to do it yourself.
----
Once installed, I rarely have to update ruby on a server.
Gems however are another matter altogether and a typical ruby
application (Rails or otherwise) is likely to require many ruby gems
(think Perl CPAN).
When I first started deploying RoR applications on CentOS or RHEL, all
of the gem RPM's lagged way behind and it was a pain. So you discover
that even if the base ruby install was RPM, you pretty much abandoned
RPM's for gems. The gem package management system is self contained and
excellent, even compiling gems that require 'native extensions' on the
fly. There are thousands of gems (again, think CPAN). No packager is
going to take on the commitment of building rpm's for all of them so
they might build RPM's for the most popular gems and they will fall
behind quickly.
So the history is - ruby RPM's from RH and Debian tended to be generic,
featureless and updated only when security issues arose (hardly ever).
Enterprise Ruby developers (the same that write/maintain passenger) came
up with a far superior ruby build, required far less memory to run,
didn't leak and was substantially faster. Why look back? Even so, the
ruby packages on say CentOS are minimal (ruby, ruby-doc, ruby-ri,
ruby-irb, ruby-dev). The rest is all gems and RPM's are not useful
there.
Craig
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
