[Rails] Installation trouble

[Ghislain MARY]

Hi all,

I am new to ruby and trying to install rails but I encounter some
difficulties. I get an error while installing actionmailer. Here is what I
get:


$ gem install actionmailer
Attempting local installation of 'actionmailer'
Local gem file not found: actionmailer*.gem
Attempting remote installation of 'actionmailer'
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:26:in `require': No
such file to load -- action_controller (LoadError)
from /usr/local/lib/site_ruby/1.8/rubygems.rb:163:in `activate'
from /usr/local/lib/site_ruby/1.8/rubygems.rb:34:in `require_gem'
from /usr/local/lib/site_ruby/1.8/rubygems/remote_installer.rb:450:in
`find_dependencies_not_installed'
from /usr/local/lib/site_ruby/1.8/rubygems/remote_installer.rb:448:in
`each'
from /usr/local/lib/site_ruby/1.8/rubygems/remote_installer.rb:448:in
`find_dependencies_not_installed'
from /usr/local/lib/site_ruby/1.8/rubygems/remote_installer.rb:364:in
`install'
from /usr/local/lib/site_ruby/1.8/rubygems/gem_commands.rb:164:in
`execute'
from /usr/local/lib/site_ruby/1.8/rubygems/gem_commands.rb:129:in
`each'
from /usr/local/lib/site_ruby/1.8/rubygems/gem_commands.rb:129:in
`execute'
from /usr/local/lib/site_ruby/1.8/rubygems/command.rb:49:in `invoke'
from /usr/local/lib/site_ruby/1.8/rubygems/cmd_manager.rb:90:in
`process_args'
from /usr/local/lib/site_ruby/1.8/rubygems/cmd_manager.rb:63:in `run'
from /usr/local/lib/site_ruby/1.8/rubygems/gem_runner.rb:9:in `run'
from /usr/bin/gem:11


knowing that:


$ gem query --local

*** LOCAL GEMS ***

actionpack (1.3.1)
Web-flow and rendering framework putting the VC in MVC.

activerecord (1.5.1)
Implements the ActiveRecord pattern for ORM.

rake (0.4.15)
Ruby based make-like utility.

sources (0.0.1)
This package provides download sources for remote gem installation


Can somebody help me with this?

Thanks,

Ghislain

 

[Trevor Wennblom]

$ gem install actionmailer
Attempting local installation of 'actionmailer'
Local gem file not found: actionmailer*.gem
Attempting remote installation of 'actionmailer'
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:26:in `require': No
such file to load -- action_controller (LoadError)

The 'action_controller' section suggests that it may have something to
do with the install of one of the Rails dependencies. Instead of doing
the components separately, try executing 'gem install rails' and answer
'y'es to the dependencies.

 

[Ghislain MARY]

Le Vendredi 21 Janvier 2005 21:24, Trevor Wennblom a écrit :

The 'action_controller' section suggests that it may have something to
do with the install of one of the Rails dependencies. Instead of doing
the components separately, try executing 'gem install rails' and answer
'y'es to the dependencies.

In fact, I was trying to install each dependency manually because I was
getting this when installing rails:


$ gem install rails
Attempting local installation of 'rails'
Local gem file not found: rails*.gem
Attempting remote installation of 'rails'
ERROR: While executing gem ... (NameError)
undefined method `perform_action' for class `ActionController::Base'

 

[Dick Davies]

Hi all,

I am new to ruby and trying to install rails but I encounter some
difficulties. I get an error while installing actionmailer. Here is what I
get:

What version of rubygems and ruby ? I had some wierd errors with cvs ruby
around rubygems 0.8.2 or so, but can't find them now - it looked vaguely
similar..

 

[Trevor Wennblom]

In fact, I was trying to install each dependency manually because I was
getting this when installing rails:


$ gem install rails
Attempting local installation of 'rails'
Local gem file not found: rails*.gem
Attempting remote installation of 'rails'
ERROR: While executing gem ... (NameError)
undefined method `perform_action' for class `ActionController::Base'

That's very strange. Does running 'gem -v' report '0.8.4'? If not, you
could try updating your gem install. Otherwise, I'd post on the Rails
mailing list.

See: http://wiki.rubyonrails.com/rails/show/MailingLists

 

[Ghislain MARY]

I've found what the problem was.

In fact, this was coming from the way ruby is packaged in Debian. I've already
seen about this on this mailing list and during my search for a solution on
the web, but never found exactly the same problem as I had.

However, I still don't know exactly what was missing. I managed to put Ruby on
Rails by doing a "manual" installation of ruby. I'll try to find what was the
missing Debian package and I'll tell you all here to help people who might
encounter the same problem later.

But the real solution to the problem would be for the ruby package in Debian
to contain all that is contained in the ruby source distribution...

See you all later

Ghislain

 

[Ghislain MARY]

The missing package was libdrb-ruby.

Can't understand why these packages are not installed when installing ruby...

 

[Adelle Hartley]

Hi,

The missing package was libdrb-ruby.

Can't understand why these packages are not installed when
installing ruby...

You might want to mention this on debian-ruby. A similar matter was raised
recently with regard to ruby-stdlib.

Adelle.

 

[Eric Schwartz]

The missing package was libdrb-ruby.

Can't understand why these packages are not installed when installing ruby...

Debian, and most distros derived from it, try to factor out
dependencies as much as humanly possible. It's not a matter of being
arrogant and thinking, "We know better than you how to distribute
ruby", it's a matter of allowing someone who doesn't care about ruby
to install the very minimum required to run a program that itself
requires ruby.

Even with the advent of broadband, this is still very important, as a
number (probably a majority) of users are still in countries where the
default is metered connections, and every extra byte costs them money.
Also, such fine (and orthogonal) dependencies allow people to create
custom LiveCDs and/or distributions that contain only what they need
(yes, a number of people use Debian as a base for embedded Linux
programming for that very reason).

However, feel free to ask the ruby maintainer to change his packaging;
he may agree with you.

-=Eric

 

[Eric Schwartz]

The missing package was libdrb-ruby.

A full list of required ruby packages for manually installing
rubygems:

ruby
libruby
libdrb-ruby
libyaml-ruby
libzlib-ruby

I'm not positive about libruby, actually.

Even if these should be included by default, about which point I am
entirely agnostic, it seems to me that it's a bug in rubygems for not
correctly reporting the error, so that the user can know which
packages to install. Having to guess is very frustrating

-=Eric

 

[Eric Schwartz]

A full list of required ruby packages for manually installing
rubygems:

ruby
libruby
libdrb-ruby
libyaml-ruby
libzlib-ruby

Also, when installing rails, I got a NameError that ActionView::Base
was not found, which is another bug-- the actual missing library was
erb, which I figured out after running gem with --debug. I don't know
gems that well-- is it really that hard to figure out the library
that's actually missing? Maybe it is, I don't know, but things like
this make it hard to recommend ruby to people who don't know why they
should care.

-=Eric

 

[Austin Ziegler]

Debian, and most distros derived from it, try to factor out
dependencies as much as humanly possible. It's not a matter of
being arrogant and thinking, "We know better than you how to
distribute ruby", it's a matter of allowing someone who doesn't
care about ruby to install the very minimum required to run a
program that itself requires ruby.

That's a fine sentiment, but there are plenty of demonstrable cases
where it's just *wrong*, Eric. Ruby has a standard library for a
reason: so that developers can expect that if Ruby is installed,
anything in that library will be there already. This isn't
guaranteed to stay static, and it will probably change over release
versions (e.g., the deprecation and removing of some libraries
between 1.6 and 1.8).

So yes, it *does* become a matter of "we know better how to
distribute Ruby than you (the language designer and maintainer) do."
If packaging policies cause programs to fail that should simply
work, then the packaging policy is quite simply put broken. There
are definitely auxiliary parts of Ruby (e.g., the ri documentation
*data*, but *not* the ri program and libraries), but the sheer
number of libraries that Ruby is broken into on Debian and Debian-
based distributions is stupid, and that's the absolute *nicest*
thing that I can say about it.

The broken application doesn't make Debian look bad, it makes the
application developer and the language look bad. I'm sorry, but the
developer didn't actually make a mistake. Either the user did for
choosing Debian or a Debian-based distro (because of stupid
packaging policies) or the Debian repackagers did. Personally, I'm
leaning toward blaming the repackagers rather than the users or
developers in this case.

-austin

 

[Austin Ziegler]

A full list of required ruby packages for manually installing
rubygems:

ruby
libruby
libdrb-ruby
libyaml-ruby
libzlib-ruby

I'm not positive about libruby, actually.

Even if these should be included by default, about which point I
am entirely agnostic, it seems to me that it's a bug in rubygems
for not correctly reporting the error, so that the user can know
which packages to install. Having to guess is very frustrating

Wrong. This is not -- and never will be -- a RubyGems bug. This is
-- and always will be -- a Debian bug. DRB, YAML, and Zlib are part
of the Ruby platform. If they're not there because of packaging
policies, then it isn't an application bug.

Additionally, RubyGems cannot and should not try to determine which
OS-specific packages may be missing -- it should be dependent upon
the Ruby platform, which includes a number of features that the ever
so wise Debian repackagers have decided aren't part of Ruby, even
though the language designer has decreed that they *are* part of
Ruby.

-austin

 

[Eric Schwartz]

Wrong. This is not -- and never will be -- a RubyGems bug. This is
-- and always will be -- a Debian bug. DRB, YAML, and Zlib are part
of the Ruby platform. If they're not there because of packaging
policies, then it isn't an application bug.

It doesn't matter. If the application needs a library, and cannot
find it, the application should report that library missing. The
application should NOT report some random library that has nothing to
do with the actual missing library as missing.

If you want to declare all of what comes in ruby-1.8.tar.gz as
"standard", that's fine. If you want to claim it's a bug that it's
not all there on a default Debian install, that's fine too-- file a
bug. But it is never correct for any application to report a bug in
class A, when in fact it's in class B. This is basic human factors--
an error message should tell the user:

*) What's wrong.
*) What the user did to cause this (if applicable)
*) What the user can do to fix it.

RubyGems, in this particular instance, fails all three criteria.

Should Debian install everything in ruby-1.8.2.tar.gz? Maybe.
Probably, even. But it is never correct in any context to report
errors incorrectly. At worst, a message to the effect of,

error loading rubygems/builder.rb: required dependencies are missing (check your installation of ruby?)

would be appropriate. After all, it's quite possible the user simply
had an error when installing ruby by hand, and somehow the relvant
files didn't get copied, or were copied, and read permissions were not
set (which can easily happen when isntalling as root with an overly
restrictive umask).

-=Eric

 

[Eric Schwartz]

After all, it's quite possible the user simply
had an error when installing ruby by hand, and somehow the relvant
files didn't get copied, or were copied, and read permissions were not
set (which can easily happen when isntalling as root with an overly
restrictive umask).

Okay, I peeked at the ruby install process, and this isn't likely to
happen. But the point remains that a failed or partial install could
be responsible for similar experiences.

-=Eric

 

[Ghislain MARY]

It doesn't matter. If the application needs a library, and cannot
find it, the application should report that library missing. The
application should NOT report some random library that has nothing to
do with the actual missing library as missing.

I totally agree on this point. The error message I was getting had nothing to
do with the real problem. So even if my installation was not well done (due
to any factor we can imagine) this should not happen. I would have gotten a
message telling me that the:
require drb
was not successful. So I consider this as a bug in rubygems.

If you want to declare all of what comes in ruby-1.8.tar.gz as
"standard", that's fine. If you want to claim it's a bug that it's
not all there on a default Debian install, that's fine too-- file a
bug. But it is never correct for any application to report a bug in
class A, when in fact it's in class B. This is basic human factors--
an error message should tell the user:

I also think that debian should install all the content of the ruby source
distribution in its package. Or do a meta-package ruby-1.8 installing all the
packages corresponding to the content of the source distribution having the
actual ruby-1.8 transformed in ruby-base-1.8. This would still allow people
wanting just the core part of ruby to have only what they want. Just an
idea...

Ghislain

 

[Eric Schwartz]

I also think that debian should install all the content of the ruby source
distribution in its package.

There is a bug open now, #286400, which requests the creation of such
a package, in a way that it would be installed by default in most
cases, and in the others, would be flagged as highly recommended. I
believe the best course of action at this point would be to add more
information to this bug report, perhaps even raising the severity if
you feel it's warranted.

-=Eric

 

[Austin Ziegler]

It doesn't matter. If the application needs a library, and cannot
find it, the application should report that library missing. The
application should NOT report some random library that has nothing
to do with the actual missing library as missing.

Mmmm. I haven't looked at this specific portion of the RubyGems
code, but I have a suspicion that if it's ultimately because libdrb
is missing, then it's trying to get an object remotely. There is
little (if anything) that RubyGems can do in the case of a Ruby that
isn't completely there when it should be.

Not only that, I'm a bit baffled that the problem was solved by the
installation of libdrb-ruby -- because there's nothing in RubyGems'
source code that requires 'drb' or 'action_controller'.

Maybe RubyGems could do something like:

"It looks like you've installed this on a variant of Debian Linux.
Change distributions because the people who package Ruby don't
know what they're doing."

No other operating system has nearly the level of problems that
Debian does -- not even the Windows distro, now that OpenSSL and
other items are present that weren't present. There's a few items
missing that would be nice (ncurses/pdcurses) but aren't super
necessary. Debian, on the other hand, has taken a deliberate
approach that *cripples* Ruby; not only that, neither Python nor
Perl are crippled the way that Ruby is.

If you want to declare all of what comes in ruby-1.8.tar.gz as
"standard", that's fine. If you want to claim it's a bug that it's
not all there on a default Debian install, that's fine too-- file
a bug. But it is never correct for any application to report a bug
in class A, when in fact it's in class B. This is basic human
factors-- an error message should tell the user:

I'm not going to disagree that RubyGems can't improve its error
messages; it can. But the reality is that this is not something that
RubyGems should ever be able to detect and prevent -- especially
since the error is coming *during the run process* and not during
the startup (e.g., not during a 'require' stage).

-austin

 

[Ghislain MARY]

Mmmm. I haven't looked at this specific portion of the RubyGems

code, but I have a suspicion that if it's ultimately because libdrb
is missing, then it's trying to get an object remotely. There is
little (if anything) that RubyGems can do in the case of a Ruby that
isn't completely there when it should be.

Not only that, I'm a bit baffled that the problem was solved by the
installation of libdrb-ruby -- because there's nothing in RubyGems'
source code that requires 'drb' or 'action_controller'.

You're right. It's the Action Pack that requires drb, not rubygems.

Ghislain

 

[Alexander Kellett]

There is a bug open now, #286400, which requests the creation of such
a package, in a way that it would be installed by default in most
cases, and in the others, would be flagged as highly recommended. I
believe the best course of action at this point would be to add more
information to this bug report, perhaps even raising the severity if
you feel it's warranted.

i wish i could. its far from wishlist imo.
if anyone that knows how to use the bugs
page on debian.org could chance it to severe
and explain how i can vote up this bug then
i'd be most grateful

debian developers should just fix this before
the rubygems developers among others are forced
to place debian specific workarounds in their
applications.

soon you'll tell me that i'm forced to write:
require 'stringclass' || die "sorry you didn't install the string
class"
in all the code that i distribute.

no chance.
sorry but the current situation is really a bit of a joke.
Alex