Prev: How to add Header information to a SOAP request
Next: ANN: Ruby 1.8.6 pl399 released
From: Thomas Lucero on 10 Feb 2010 11:59
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 Lavena: 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 Lavena: 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 - http://github.com/dcu/gem2deb
8. thwarted (alpha 2008/12/05) gem2deb -
http://github.com/thwarted/gem2deb
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 Chambers 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.
--
Posted via http://www.ruby-forum.com/.

From: thomasl on 10 Feb 2010 14:10
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:
>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.
From: Rick DeNatale on 10 Feb 2010 15:42
On Wed, Feb 10, 2010 at 11:59 AM, Thomas Lucero
<tllucero(a)stardevsoft.com> wrote:
> 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.

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: http://www.linkedin.com/in/rickdenatale

From: Marnen Laibow-Koser on 10 Feb 2010 15:53
Rick Denatale wrote:
> On Wed, Feb 10, 2010 at 11:59 AM, Thomas Lucero
> <tllucero(a)stardevsoft.com> 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: http://www.linkedin.com/in/rickdenatale

Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen(a)marnen.org
--
Posted via http://www.ruby-forum.com/.

First  |  Prev  | 
Pages: 1 2
Prev: How to add Header information to a SOAP request
Next: ANN: Ruby 1.8.6 pl399 released