Problems with RubyGems on a Debian machine

Ruby
1

I wasn’t quite sure if I should of posted this in the Ruby forum or the
Ruby on Rails forum but here it goes.

So I’ve been trying to install rails onto a Debian (Lenny) machine of
mine. I assumed from the readings I have done that RubyGems is supposed
to take care of dependencies for me, but apparently on my machine it
doesn’t. It tries to install rails and then complains that I need a
version of Rack 1.0.0 or newer. Now RubyGems will let me install
packages that don’t have the tree of dependencies like rails and so Rack
and Rake install just fine. But when I go back to installing Rails, it
still complains that I do not have rack installed or it is not a new
enough of a version. A friend of mine mentioned something about a file
the RubyGems uses to handle dependencies that can get messed up if
something goes wrong during an installation but I don’t know anything
about that. Can anyone help?

2

Just some additional information I found after searching the gem
directory. So if I try ‘gem install rails’ the first time, it stops at
the normal rack dependency error. When I check the gems installed, it
installed activerecord, activesupport, rack, and rake. When I try ‘gem
install rails’ again, I get the same error message, but this time I see
that actionpack is also installed. However, repeating ‘gem install
rails’ past this will not install any additional gems. The exact error
message is:

ERROR: Error installing rails:
actionpack requires rack (~> 1.0.0, runtime)

Again, not sure if this is a Rails specific issue I should just move the
to Ruby on Rails forum/mailing list but since this seems to be an error
with RubyGems and not Rails, I thought it would be appropriate to post
here. Again, any help would be very much appreciated.

3

Greg C. wrote:

still complains that I do not have rack installed or it is not a new
enough of a version. A friend of mine mentioned something about a file
the RubyGems uses to handle dependencies that can get messed up if
something goes wrong during an installation but I don’t know anything
about that. Can anyone help?

Do you use debian’s rubygems package?

4

On Feb 5, 9:38 am, Greg C. [email protected] wrote:

    actionpack requires rack (~> 1.0.0, runtime)

This issue was discovered and discussed here:

http://rubyforge.org/pipermail/rubygems-developers/2010-January/005141.html

The issue is that there are components that define runtime and
development time dependencies. RubyGems up to version 1.3.5 was not
capable of resolve that recursive issue.

Again, not sure if this is a Rails specific issue I should just move the
to Ruby on Rails forum/mailing list but since this seems to be an error
with RubyGems and not Rails, I thought it would be appropriate to post
here. Again, any help would be very much appreciated.

In the mean time, you can manually install rack and then proceed with
the normal gem installation.

The fix will be part of next RubyGems release.

5

Luis L. wrote:

On Feb 5, 9:38�am, Greg C. [email protected] wrote:

� � � � actionpack requires rack (~> 1.0.0, runtime)

This issue was discovered and discussed here:

http://rubyforge.org/pipermail/rubygems-developers/2010-January/005141.html

The issue is that there are components that define runtime and
development time dependencies. RubyGems up to version 1.3.5 was not
capable of resolve that recursive issue.

Again, not sure if this is a Rails specific issue I should just move the
to Ruby on Rails forum/mailing list but since this seems to be an error
with RubyGems and not Rails, I thought it would be appropriate to post
here. �Again, any help would be very much appreciated.

In the mean time, you can manually install rack and then proceed with
the normal gem installation.

The fix will be part of next RubyGems release.

Well my problem is mostly that when I do install Rack, it still can’t
see it in the dependencies and so cannot proceed to install Rails.

Ralf M. wrote:

Greg C. wrote:

still complains that I do not have rack installed or it is not a new
enough of a version. A friend of mine mentioned something about a file
the RubyGems uses to handle dependencies that can get messed up if
something goes wrong during an installation but I don’t know anything
about that. Can anyone help?

Do you use debian’s rubygems package?

Yes I did use debian’s rubygems package, specifically whichever one is
hosted on the Rochester Institute of Technology mirror.

6

Known problem. Both Debian apt/aptitude/Synaptic and RubyGems keep track
of dependencies. However, they don’t play well together.

From http://blog.phusion.nl Installing Ruby/Rails software on Debian and
Ubuntu Linux distributions has been less than ideal until now. Ruby has
a package manager called RubyGems, but Debian-based distributions have
their own package manager, namely Apt, which manages the entire system
and is preferred by most Debian users. RubyGems does not integrate well
with Apt and cannot handle native Debian package dependencies. But on
the other hand, Ruby software provided through the current Debian Apt
repositories are not always up-to-date, e.g. the latest Rails version is
often not available.

Issues and attempted solutions include (some apply to all RubyGems,
others only if attempting Rails 3):

  1. Debian specifically disables gem update --system
  2. Use ruby gem rvm to help isolate issues of different ruby
    environments - including ruby version and gem sets.
  3. (ruby 1.9.1) From Luis L.: Try … RubyGems that cames with 1.9.1
    instead of the 1.3.5 on top of it.
  4. use ruby 1.8.7 (ruby 1.9.1 and 1.9.2 work for some but not all
    people)
  5. Due to a rubygems bug, you must uninstall all older versions of
    bundler for 0.9 to work
  6. So far rails 3.0.0.beta and ruby 1.9.1 are not friends. In order to
    install rails, you need rubygems 1.3.5, but ruby 1.9.1 has rubygems
    1.3.1 bundled.
    Workaround 1: From Luis L.: Try … RubyGems that cames with 1.9.1
    instead of the 1.3.5 on top of it.
    Workaround 2. is to remove your manually installed rubygems from 1.9.x.
    Workaround 3. you can gem install --force.

Or, convert gems to deb
7. dcu (alpha 2009/10/17) gem2deb - GitHub - dcu/gem2deb: convert ruby gem to debian package
8. thwarted (alpha 2008/12/05) gem2deb -
GitHub - thwarted/gem2deb: Takes a URL to a .gem or tar'ed gem and does the brute force work of converting it to a .deb package
9. Phusion/hongli (beta, Debian etch only!) DebGem - free now, pay
later.

My suggestions are (for ruby 1.9.x):

  1. Uninstall all ruby gems,
  2. Revert to RubyGems version 1.3.1
  3. Install ruby gem rvm.
  4. Use rvm to isolate the issues.

Greg C. wrote:
I wasn’t quite sure if I should of posted this in the Ruby forum or the
Ruby on Rails forum but here it goes.

So I’ve been trying to install rails onto a Debian (Lenny) machine of
mine. I assumed from the readings I have done that RubyGems is supposed
to take care of dependencies for me, but apparently on my machine it
doesn’t. It tries to install rails and then complains that I need a
version of Rack 1.0.0 or newer. Now RubyGems will let me install
packages that don’t have the tree of dependencies like rails and so Rack
and Rake install just fine. But when I go back to installing Rails, it
still complains that I do not have rack installed or it is not a new
enough of a version. A friend of mine mentioned something about a file
the RubyGems uses to handle dependencies that can get messed up if
something goes wrong during an installation but I don’t know anything
about that. Can anyone help?

Yes I did use debian’s rubygems package, specifically whichever one is
hosted on the Rochester Institute of Technology mirror.

7

On Wed, Feb 10, 2010 at 11:59 AM, Thomas Lucero
[email protected] wrote:

repositories are not always up-to-date, e.g. the latest Rails version is
often not available.

Yep. IMHO the requirements of the usual LAMP user of a Debian or other
packaged Linux distro are not the same as the typical rails developer.
The former usually wants a fairly stable platform, the latter wants
to keep up with the rapidly changing universe of Ruby, Rails, gems,
…

Ruby developers are used to, and a lot expect, the ability to quickly
upgrade, and even deal with multiple versions on the same box for
different applications. Having multiple versions of ruby gems
installed has long been a feature of gems. Rails developers use
techniques like unpacking gems and rails itself into a vendor
directory of the app to allow different apps with different
requirements as to versions and sets of gems to run on the same box.
And today the state of the art is tools like RVM which allow multiple
versions and implementations of Ruby to coexist and be selectable.
You can have various versions of MRI (1.8.6, 1.8.7, 1.9.1) along with
Rubinius, JRuby, MagLev, (and on a Mac MacRuby).

The Debian packaging system is really built around having one version
of a given package installed at a time. The maintainers of ruby
packages for debian, occasionally take new versions and repackage
them. Waiting for that process is unacceptable for a lot of Ruby
developers. Also the repackaging sometimes takes some interesting
twists, at one point rails got repackaged, and the rails binary was
re-written as a bash shell script! I don’t know if that’s still the
case because…

Early on in my use of Ruby, I was advised to just say no to the
packaged versions and build from source, On a Debian system just make
sure to install it somewhere which the packaging system doesn’t muck
with, like /user/local/…

And I pretty much do the same thing now that most of my development is
on OS X.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: Rick DeNatale - Developer - IBM | LinkedIn

8

My previous suggestion doesn’t work on Debian using apt. Lenny has
rubygems 1.2.0-3, while squeeze (testing) has rubygems 1.3.5-2.
Neither has rubygems 1.3.1.

This, however, did work. It’s not ready for production yet.
Debian squeeze (testing machine) - ruby 1.9.1.376-1 rubygems 1.3.5-2
It turns out all I needed was the right version of rack-mount. So I
did this:

gem install tzinfo builder memcache-client rack rack-test rack-mount
erubis mail text-format thor bundler i18n
sudo gem install rack-mount --version 0.4.0
sudo gem install rails --pre

Thomas Lucero said:

9

Rick Denatale wrote:

On Wed, Feb 10, 2010 at 11:59 AM, Thomas Lucero
[email protected] wrote:

repositories are not always up-to-date, e.g. the latest Rails version is
often not available.

Yep. IMHO the requirements of the usual LAMP user of a Debian or other
packaged Linux distro are not the same as the typical rails developer.
The former usually wants a fairly stable platform, the latter wants
to keep up with the rapidly changing universe of Ruby, Rails, gems,
…

Ruby developers are used to, and a lot expect, the ability to quickly
upgrade, and even deal with multiple versions on the same box for
different applications. Having multiple versions of ruby gems
installed has long been a feature of gems. Rails developers use
techniques like unpacking gems and rails itself into a vendor
directory of the app to allow different apps with different
requirements as to versions and sets of gems to run on the same box.
And today the state of the art is tools like RVM which allow multiple
versions and implementations of Ruby to coexist and be selectable.
You can have various versions of MRI (1.8.6, 1.8.7, 1.9.1) along with
Rubinius, JRuby, MagLev, (and on a Mac MacRuby).

Right.

The Debian packaging system is really built around having one version
of a given package installed at a time. The maintainers of ruby
packages for debian, occasionally take new versions and repackage
them. Waiting for that process is unacceptable for a lot of Ruby
developers. Also the repackaging sometimes takes some interesting
twists, at one point rails got repackaged, and the rails binary was
re-written as a bash shell script! I don’t know if that’s still the
case because…

Early on in my use of Ruby, I was advised to just say no to the
packaged versions and build from source, On a Debian system just make
sure to install it somewhere which the packaging system doesn’t muck
with, like /user/local/…

I haven’t used Debian as such for Ruby, but on Ubuntu the packaged Ruby
is fine. No reason to build from source.

And I pretty much do the same thing now that most of my development is
on OS X.

What a waste of time, effort, and disk space. Leopard’s version of MRI
1.8 is absolutely fine. I have had no problems with it at all.

–
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: Rick DeNatale - Developer - IBM | LinkedIn

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]