From: Austin Ziegler Date: 2005-01-26T12:33:15+09:00 Subject: Re: [Rails] Installation trouble On Wed, 26 Jan 2005 06:36:00 +0900, Eric Schwartz wrote: > Austin Ziegler writes: >> 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. 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 -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca