It’s just data

Rails on Jaunty

One of these days, aptitude install rails will be all that is needed.  With Jaunty, this is not quite the case, but nearly so.  What you get is Ruby 1.8.7 (good), gem 1.3.1 (good), and rails 2.1.0 (vintage June 2008).  Unfortunately, any rails commands will result in nine lines of the form /usr/lib/ruby/1.8/xmlsimple.rb:275: warning: already initialized constant.  Upgrading to 2.3.2 (vintage March 2009) is as simple as:

sudo gem install rails
export PATH=/var/lib/gems/1.8/bin/:$PATH

This also eliminates the warnings.  The last line should be dropped into your .bashrc file.

My position on this still stands. One of these days, distribution package maintainers will realise that including rubygems and associated gems in their package tree does more harm than good.

Posted by Nathan de Vries at

With Ruby 1.9, rubygems is part of ruby.  This is a tough problem.

Meanwhile, I have instructions in the Agile Web Development with Rails book that includes installing libopenssl-ruby with aptitude.  That’s totally non-obvious, and outside of what gems will do for you.  I like the fact that update-manager will keep ruby, libopenssl, and sqlite3 libraries up to date.

Aptitude has an option for build-dep which will install everything you need to build a package, but not the package itself.  It would be nice if it included a gem-dep option.

Posted by Sam Ruby at

submitted by gthank [link] [0 comments]...

Excerpt from programming: what's new online at

The reason distributions include ruby gems in their packaging systems is because there are MANY great pieces of software they want to offer in their repo that depend on rubygems.  Now, they could inflate any package they ship that is written in python, ruby, perl, haskell, or whatever and include all the dependent libraries.. but that would mean when you installed two programs that both depended on the same library, that library would be installed twice.  Now the distribution would have to update every program that depended on some library when the library was upgraded, even if it’s not necessary.  This causes a major bandwidth and disk strain on their servers, and all the mirrors servers, and on the distribution developers themselves.

It’s not ideal, but it’s way better than the sane alternative.  You may say that they shouldn’t ship ANY ruby libraries then.. but that isn’t even a sane answer.  The arch-haskell project and the now defunct arch-perl projects were what I consider to be the best answer. They automatically generated the archlinux packages from the respective systems (cabal and cpan) with correct dependencies and everything.  You are only as out of date as the last time these package generators were run.

Your real complaint is that some gems are out of date for your distribution.  I think automatic “repo converters” are the answer to that, but it’s a bit of a project to take on first time around.

Posted by Codemac at

debgem looks worth watching.

Posted by Sam Ruby at

Another thing worth bookmarking: Eva’s useful guide to Ubuntu 9.04

Posted by Sam Ruby at

Upgrading from gem 1.3.1 to 1.3.3:

sudo gem install rubygems-update
sudo `which update_rubygems`
gem -v
Posted by Sam Ruby at

When doing the following: export PATH=/var/lib/gems/1.8/bin/:$PATH
It works, however, after a reboot it doesn’t anymore.

Posted by Bryan at

Bryan, you can add that line to your .bashrc file and it will be processed each time you log on.

Since a new version of gems has come out since I wrote these instructions, my current approach to upgrading a fresh install of Jaunty is as follows:

sudo apt-get install rails
sudo gem install rubygems-update
sudo /var/lib/gems/1.8/bin/update_rubygems
sudo gem install rails

With the above instructions, there is no need to update your PATH.

Posted by Sam Ruby at

Solution found for undefined method ‘manage_gems’.

Posted by Sam Ruby at

Add your comment