When I first got involved with Red Hat (back with 5.2 in the early 90's) I learned the hard way not to use language-specific packaging systems like CPAN for Perl because they'd conflict with RPM's database and make it much harder to manage what was installed on my system. If I now need a package for which no RPM is available, I'll use a utility like cpanspec to repackage it into an RPM and install that.
Now I'm starting to work with Ruby and apparently it has its own packages called "gems". How do people deal with making Ruby and RPM get along?
I'm trying to build Diaspora, an open source alternative to Facebook, and it wants me to install a ton of gems. I'm working on a "disposable" machine that I can re-image at will, so I let it use Ruby's "bundle install" command to dump all the gems from the Ruby repositories into their system location. But in a "real" installation I'd want to do this with RPM, repackaging gems as needed. What's available to do this properly?
https://github.com/diaspora/diaspora/wiki/Installing-and-Running-Diaspora
--On Saturday, October 08, 2011 4:56 AM -0700 Kenneth Porter shiva@sewingwitch.com wrote:
How do people deal with making Ruby and RPM get along?
No sooner do I hit the send button than I realize how to frame the question to Google and find the answer. For the list archives:
On Sat, 2011-10-08 at 03:56 -0700, Kenneth Porter wrote:
When I first got involved with Red Hat (back with 5.2 in the early 90's) I learned the hard way not to use language-specific packaging systems like CPAN for Perl because they'd conflict with RPM's database and make it much harder to manage what was installed on my system. If I now need a package for which no RPM is available, I'll use a utility like cpanspec to repackage it into an RPM and install that.
Now I'm starting to work with Ruby and apparently it has its own packages called "gems". How do people deal with making Ruby and RPM get along?
I'm trying to build Diaspora, an open source alternative to Facebook, and it wants me to install a ton of gems. I'm working on a "disposable" machine that I can re-image at will, so I let it use Ruby's "bundle install" command to dump all the gems from the Ruby repositories into their system location. But in a "real" installation I'd want to do this with RPM, repackaging gems as needed. What's available to do this properly?
https://github.com/diaspora/diaspora/wiki/Installing-and-Running-Diaspora
---- CentOS 6 is new so there's little experience with running ruby packages on it but there's really no problem with running 'gem install $SOME_PACKAGE' on any system. Realistically, the available rpm packages are never going to keep up with the gems so after you get the base ruby rpm packages installed (ruby/ruby-irb/ruby-ri/ruby-rdoc/ruby-gems) you should probably just quit there and use the built-in gem package provider to do everything else. Also, if you are talking about something like a Ruby on Rails solution, the more organized setups will use 'bundler' to get the application up to speed rather quickly.
Some people use RVM (ruby virtual manager which will allow you to have multiple versions of ruby on the same computer). This pretty much steps outside of the native rpm packaging completely.
CentOS 5.x however is a different beast and the ruby implementation is 1.8.5-X which is too old to do much of anything and I've found the simplest thing to do is not use any CentOS ruby packages whatsoever and simply use 'Enterprise ruby'
Craig
--On Saturday, October 08, 2011 6:29 AM -0700 Craig White craigwhite@azapple.com wrote:
CentOS 6 is new so there's little experience with running ruby packages on it but there's really no problem with running 'gem install $SOME_PACKAGE' on any system. Realistically, the available rpm packages are never going to keep up with the gems so after you get the base ruby rpm packages installed (ruby/ruby-irb/ruby-ri/ruby-rdoc/ruby-gems) you should probably just quit there and use the built-in gem package provider to do everything else. Also, if you are talking about something like a Ruby on Rails solution, the more organized setups will use 'bundler' to get the application up to speed rather quickly.
That makes sense.
I played a little with gem2rpm but to really be useful there should be a yum repository of standard gems that tracks whatever ruby's normal upstream repositories hold (its CPAN equivalent).
On Sat, 2011-10-08 at 05:46 -0700, Kenneth Porter wrote:
--On Saturday, October 08, 2011 6:29 AM -0700 Craig White craigwhite@azapple.com wrote:
CentOS 6 is new so there's little experience with running ruby packages on it but there's really no problem with running 'gem install $SOME_PACKAGE' on any system. Realistically, the available rpm packages are never going to keep up with the gems so after you get the base ruby rpm packages installed (ruby/ruby-irb/ruby-ri/ruby-rdoc/ruby-gems) you should probably just quit there and use the built-in gem package provider to do everything else. Also, if you are talking about something like a Ruby on Rails solution, the more organized setups will use 'bundler' to get the application up to speed rather quickly.
That makes sense.
I played a little with gem2rpm but to really be useful there should be a yum repository of standard gems that tracks whatever ruby's normal upstream repositories hold (its CPAN equivalent).
---- gem development is too fast/furious for any type of distribution native packaging to reasonably keep up. I've never actually looked at any gem2rpm thing and the thought of doing so seems ridiculous to me.
I've been using ruby stuff since 2005 and I pretty much avoid the distribution packages. FWIW, I don't use the native RPM ruby packages on CentOS and likewise, don't use the native DPKG ruby packages on Ubuntu and use Enterprise Ruby either.
Eventually it becomes obvious that to do anything serious with ruby, the OS packages lag behind and become the problem. If you are doing lightweight things, then you can probably get by. Certainly for someone's first foray into ruby, CentOS 6 ruby packages are sufficient and once you have the base installation, the gem packaging provider can handle things quite well.
Craig