Saturday, March 15, 2008

Ruby on Rails Upgrade Woes

We were having mysterious seg faults with some long-running Rails tasks on our server, so I thought it might time for some software updates. Nothing too radical just Ruby 1.8.5 -> 1.8.6 and Rails 1.2.3 -> 1.2.6. In the process I discovered that a new version of RubyGems was available, so I thought it might be good to upgrade it at the same time, Gem 0.9.4 -> 1.0.1. The Ruby, Gem, and Rails upgrades went fine, but ultimately the Gem upgrade proved to be a bad idea. The upgrade seemed to have lost all my installed Gems, except for the just upgraded Rails and its dependencies. Some minor dismay, but no big deal I thought, I've got a list of the Gems we needed, so I'll end up updating all the Gems at the same time too. Everything seemed to be going OK, until I discovered that the ruby-openid Gem had a dependency on a method from the older versions, namely Kernel#require_gem was removed and replaced with just Kernel#gem. As far as I can tell this was nothing but a name change which begs the question why do this when it is almost guaranteed to break a bunch of other code. Anyway, I had to revert back to a previous version of RubyGems, 0.9.5, which seems to have fixed the problem. All in all a rather nerve wracking undertaking.

As I type this, a task which was previously throwing seg faults has been running for about 30 minutes without error, so my hope is that all this trouble has at least solved that problem.

3 comments:

Weyus said...

I've had a terrible experience trying to do a full stack upgrade of Ruby and Rails (Ruby 1.8.4 -> 1.8.6, Rails 1.1.6 -> 1.2.6). Two changes in core Ruby classes caused problems for me, plus the continued poor support for MS SQL Server in ActiveRecord continues to plague me. It may have put me off upgrading my RoR apps. any more.

Tilo said...

Same thing happened to me after
upgrading "gem" itself...

A little research in the guts of my machine showed that all my old gems where still there under

/usr/lib/ruby/gems/1.8/gems/

... but because I have a 64-bit machine, the new gem version uses /usr/lib64/ruby/gems/1.8/gems/
as the default path for the gems and doesn't find the old gems...

Two possible solutions:

1) do a directory listing
of the old location, and
re-install all gems with
--version =whatever

2) copy the old directory
structure over to lib64

e.g.
** careful with that axe!! **
cd /usr/lib/ruby/gems/1.8/
tar -cf - . | (cd /usr/lib64/ruby/gems/1.8 ; tar -xf -)

Tilo said...

even easier:

cd /usr/lib64/ruby
mv gems gems.old
ln -s /usr/lib/ruby/gems .


est voila! it works again..
all future gems will be installed
under the /usr/lib/ruby directory
regardless if they are 32 or 64 bit.