RubyGems 0.9.5 adds several new features and fixes several bugs.

To upgrade to the latest RubyGems:

gem update --system

To upgrade to the latest RubyGems by hand:

* Download RubyGems from http://rubyforge.org/frs/?
group_id=126&release_id=16500
* `gem install rubygems-update-0.9.5.gem`
* `update_rubygems`

To install RubyGems from scratch:

* Download RubyGems source .tgz or .zip file from
http://rubyforge.org/frs/?group_id=126&release_id=16500
* Unpack the source .tgz or .zip
* `ruby setup.rb`

To install RubyGems on Ruby 1.9 update your ruby trunk checkout and
reinstall.

To file bugs:

http://rubyforge.org/tracker/?func=a...d=126&atid=575

When filing a bug, `gem env` output will be ful in diagnosing the
issue.

If you find a bug where RubyGems crashes, please provide debug
output. You can do that with `gem --debug the_command`. For example:

$ gem --debug unknown_command
Exception `RuntimeError' at [...]/rubygems/command_manager.rb:114
- Unknown command unknown_command
ERROR: While executing gem ... (RuntimeError)
Unknown command unknown_command
[...]/rubygems/command_manager.rb:114:in `find_command'
[...]/rubygems/command_manager.rb:103:in `process_args'
[...]/rubygems/command_manager.rb:74:in `run'
[...]/rubygems/gem_runner.rb:39:in `run'
/usr/local/bin/gem:22

=== Changes

Select new features include:

* Automatic installation of platform gems
* New bandwidth and memory friendlier index file format
* "Offline" mode (--no-update-sources)
* Bulk update threshold can be specified (-B, --bulk-threshold)
* New `gem fetch` command
* `gem` now has "really verbose" output when you specify -v
* Ruby 1.9 compatible

Other changes include:

* Time::today is deprecated and will be removed at a future date
* `gem install --include-dependencies` (-y) is now deprecated since
it is the
default, use --ignore-dependencies to turn off automatic dependency
installation
* `gem.bat` and bin stubs on mswin platforms are improved and
compatible with
the One-Click Installer
* Multi-version diamond dependencies only are installed once
* Bulk index updates take less memory
* -V now enables verbose instead of -v to avoid collision with --
version's -v
* `gem install -i` makes sure all depenencies are installed
* `gem update --system` reinstalls into the prefix it was originally
installe in
* `gem update --system` respects --no-rdoc and --no-ri flags
* HTTP basic authentication support for proxies
* Gem::Specification#platforms should no longer be a String, use
Gem::Platfor::CURRENT when building binary gems instead
* `gem env` has more diagnostic information
* require 'rubygems' loads less code
* sources.gem is gone, RubyGems now uses built-in defaults
* `gem install --source` will no longer add --source by default, use
`gem souces --add` to make it a permanent extra source
* `gem query` (list) no longer prints details by default
* Exact gem names are matched in various places
* mkrf extensions are now supported
* A gem can depend on a specific RubyGems version
* `gem_server` is now `gem server`
* `gemlock` is now `gem lock`
* `gem_mirror` is now `gem mirror`
* `gemwhich` is now `gem which`
* `gemri` is no longer included with RubyGems
* `index_gem_repository.rb` is now `gem generate_index`
* `gem` performs more validation of parameters
* Removed gem* commands are now replaced with stubs that warn
* Custom rdoc styles are now supported
* Gem indexer no longer removes quick index during index creation
* Kernel#require only rescues a LoadError for the file being required
now
* `gem dependencies` can now display some information for remote gems

=== Special Thanks

* Daniel Berger for win32 support and testing
* Luis Lavena for win32 support and testing
* Tom Copeland for testing and releasing the new indexer
* Wilson Bilkovich for the new Marshal index format
* To the rest of the RubyGems bug reporters and patch contributors

The full set of changes including contributors is included in the
ChangeLog.

=== Platforms

RubyGems now automatically handles platform gems. This means that
`gem install` will no longer prompt for gem selection. RubyGems uses
Ruby's built-in configuration to match the running ruby's platform to
choose the correct gem to install. The automatically chosen platform
may be overridden with the --platform option.

The dependency, fetch, install, outdated, specification, uninstall
and update commands all respond to --platform.

For more information, see `gem platforms`

=== Thanks

Keep those gems coming!

-- Jim & Chad & Eric (for the RubyGems team)


--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

I got caught by some "tired at the end of the day" stupidity...

I was using the Ubuntu (apt-get installed) package of RubyGems. Go
figure if you do a 'gem update --system' in this situation it makes a
mess of things.

I choose to try gems out this way because every time I've installed Gems
from source to some prefix other than /usr/lib it's managed to find
some way to not work or be otherwise inconvenient.

RubyGems has really become the one thing about Ruby I dislike.



--
Posted via http://www.ruby-forum.com/.

Eric Hodel wrote:
> RubyGems 0.9.5 adds several new features and fixes several bugs.
>

RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
gem.

I just create an issue on the RubyForge tracker :

[#15759] rubygems 0.9.5 cannot install ruby-debug-ide

Cheers.

Chauk-Mean.
--
Posted via http://www.ruby-forum.com/.

On Nov 20, 2007 1:35 AM, Eric Hodel <drbrain@segment7.net> wrote:
> RubyGems 0.9.5 adds several new features and fixes several bugs.
> [...]

Just a quick note to mention that Mac OS X 10.5 is now fully supported
by this release. Updating to it should not break Leopard's Ruby
configuration.

Laurent

Chauk-Mean P. wrote:
> Eric Hodel wrote:
>> RubyGems 0.9.5 adds several new features and fixes several bugs.
>
> RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
> gem.
>
> I just create an issue on the RubyForge tracker :
>
> [#15759] rubygems 0.9.5 cannot install ruby-debug-ide
>

I forgot to mention that I only use local installation of gems that I
already have downloaded (offline installation).

I tried forcing a local installation of ruby-debug-ide-0.1.9.gem and
this works :
gem install -l ruby-debug-ide

It's a bit strange as I have been able to install ruby-debug-base
(ruby-debug-base-0.9.3-mswin32.gem) without the local flag (-l).

Cheers.

Chauk-Mean.
--
Posted via http://www.ruby-forum.com/.

On Nov 20, 2007 12:53 AM, Michael Greenly <mgreenly@gmail.com> wrote:
> I got caught by some "tired at the end of the day" stupidity...
>
> I was using the Ubuntu (apt-get installed) package of RubyGems. Go
> figure if you do a 'gem update --system' in this situation it makes a
> mess of things.
>
> I choose to try gems out this way because every time I've installed Gems
> from source to some prefix other than /usr/lib it's managed to find
> some way to not work or be otherwise inconvenient.
>
> RubyGems has really become the one thing about Ruby I dislike.
>

My way of looking a this is the brain-dead packaging of Ruby on debian
is the one thing about Ubuntu (and Debian based distros) that *I*
dislike.

The problems you've experienced, I think, come from trying to mix
debian packaged ruby with source installed gems.

When I first started using Ruby on Ubuntu I ran into problems like
this. At Andy Hunt's suggestion I installed both Ruby and rubygems
from source and haven't looked back.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

Rick Denatale wrote:
> On Nov 20, 2007 12:53 AM, Michael Greenly <mgreenly@gmail.com> wrote:
>> RubyGems has really become the one thing about Ruby I dislike.
>>
>
> My way of looking a this is the brain-dead packaging of Ruby on debian
> is the one thing about Ubuntu (and Debian based distros) that *I*
> dislike.
>
> The problems you've experienced, I think, come from trying to mix
> debian packaged ruby with source installed gems.
>
> When I first started using Ruby on Ubuntu I ran into problems like
> this. At Andy Hunt's suggestion I installed both Ruby and rubygems
> from source and haven't looked back.
>
> --
> Rick DeNatale
>
> My blog on Ruby
> http://talklikeaduck.denhaven2.com/

Hardly... in all package managed systems /usr/lib belongs to the package
manager. No other application should ever be mucking around in there.
This is not something unique to Debian based systems. It's just that
Debian users tend to be more more vocal about these policies.

The system package currently in Ubuntu for RubyGems just about gets it
right. They most likely should of disabled the 'system' update feature
so that it wasn't possible to do what I did.

On the other hand if the upstream RubyGems would actually allow for the
concept that it may live in /usr/lib but not be allowed to manipulate
anything there it would make life a lot easier.

Now that (according to the release notes) it correctly updates when
installed to different prefixes I guess I'll try source a source install
to /usr/local again.

--
Posted via http://www.ruby-forum.com/.

On Nov 20, 2007, at 4:33 AM, Chauk-Mean P. wrote:

> Eric Hodel wrote:
>> RubyGems 0.9.5 adds several new features and fixes several bugs.
>>
>
> RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
> gem.
>
> I just create an issue on the RubyForge tracker :
>
> [#15759] rubygems 0.9.5 cannot install ruby-debug-ide

I just ran into a new RubyGems 0.9.5 issue this morning as well:

$ sudo gem install rmagick
Password:
Bulk updating Gem source index for: http://gems.rubyforge.org
Building native extensions. This could take a while...
Successfully installed rmagick-1.15.10
1 gem installed
Firefly:~/Documents/weddingbook james$ ruby -rubygems -e 'require
"RMagick"'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- RMagick.so (LoadError)
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/
custom_require.rb:27:in `require'
from /usr/local/lib/ruby/site_ruby/1.8/RMagick.rb:11
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:
27:in `gem_original_require'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/
custom_require.rb:27:in `require'
from -e:1

I'll go file a bug.

James Edward Gray II

Chauk-Mean P. wrote:
> Chauk-Mean P. wrote:
>> Eric Hodel wrote:
>>> RubyGems 0.9.5 adds several new features and fixes several bugs.
>>
>> RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
>> gem.
>>
>> I just create an issue on the RubyForge tracker :
>>
>> [#15759] rubygems 0.9.5 cannot install ruby-debug-ide
>>
>
> I tried forcing a local installation of ruby-debug-ide-0.1.9.gem and
> this works :
> gem install -l ruby-debug-ide
>
> It's a bit strange as I have been able to install ruby-debug-base
> (ruby-debug-base-0.9.3-mswin32.gem) without the local flag (-l).
>

I think that I have understood what's happening :
- rubygems 0.9.5 includes dependencies during installation by default
now
- when I first install ruby-debug-base locally (without -l), it works as
this gem has no dependency on other gems
- then when I tried to install ruby-debug-ide locally (again without
-l), it fails as it seems that rubygems tries to install the required
dependency (ruby-debug-base) remotely and not locally.

Forcing the local installation with -l solves my problem.

This raises two issues :
1- rubygems seems to not take care of gems that are already installed
(during the dependency checking)
2- rubygems should try to install dependency gems locally before
remotely.

Cheers.

Chauk-Mean.
--
Posted via http://www.ruby-forum.com/.

Michael Greenly wrote:
> Hardly... in all package managed systems /usr/lib belongs to the package
> manager. No other application should ever be mucking around in there.
> This is not something unique to Debian based systems. It's just that
> Debian users tend to be more more vocal about these policies.

Let me emphasize what you just said. /usr/lib belongs to the package
manager on all distros! There's a *reason* the Ruby source and most
other upstream sources install to ("--prefix" in "configure")
*/usr/local* rather than */usr* by default. So ... your options are

1. Work with the packages as supplied by your distro.
2. *Don't* install the packages supplied by your distro -- use upstream
source and put things in /usr/local.
3. Complain and whine to busy people who will blow you off.

On 11/20/07, Michael Greenly <mgreenly@gmail.com> wrote:
> I got caught by some "tired at the end of the day" stupidity...
>
> I was using the Ubuntu (apt-get installed) package of RubyGems. Go
> figure if you do a 'gem update --system' in this situation it makes a
> mess of things.

That doesn't surprise me. I don't use the Ubuntu or Debian versions of
Ruby; they're too broken by nonsensical policies to use.

> I choose to try gems out this way because every time I've installed Gems
> from source to some prefix other than /usr/lib it's managed to find
> some way to not work or be otherwise inconvenient.

It's not /usr/lib. I have RubyGems installed in /usr/local/lib,
because I have *Ruby* in /usr/local. If you're not going to put
RubyGems in the same place as Ruby, you're going to have to go to a
little extra effort.

> RubyGems has really become the one thing about Ruby I dislike.

It's probably because you're not using it the easy way.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * http://www.halostatue.ca/feed/
* austin@zieglers.ca

On Nov 20, 2007 10:30 AM, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> Michael Greenly wrote:
> > Hardly... in all package managed systems /usr/lib belongs to the package
> > manager. No other application should ever be mucking around in there.
> > This is not something unique to Debian based systems. It's just that
> > Debian users tend to be more more vocal about these policies.
>
> Let me emphasize what you just said. /usr/lib belongs to the package
> manager on all distros! There's a *reason* the Ruby source and most
> other upstream sources install to ("--prefix" in "configure")
> */usr/local* rather than */usr* by default. So ... your options are
>
> 1. Work with the packages as supplied by your distro.
> 2. *Don't* install the packages supplied by your distro -- use upstream
> source and put things in /usr/local.

Which is what I did on ubuntu, I just wasn't explicit about where I
installed in my post.

> 3. Complain and whine to busy people who will blow you off.

<G>

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On 11/20/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> Michael Greenly wrote:
> > Hardly... in all package managed systems /usr/lib belongs to the package
> > manager. No other application should ever be mucking around in there.
> > This is not something unique to Debian based systems. It's just that
> > Debian users tend to be more more vocal about these policies.
>
> Let me emphasize what you just said. /usr/lib belongs to the package
> manager on all distros! There's a *reason* the Ruby source and most
> other upstream sources install to ("--prefix" in "configure")
> */usr/local* rather than */usr* by default. So ... your options are
>
> 1. Work with the packages as supplied by your distro.
> 2. *Don't* install the packages supplied by your distro -- use upstream
> source and put things in /usr/local.
> 3. Complain and whine to busy people who will blow you off.

4. Complain to your distro manager to be more sensible when it comes
to Ruby. Look closely at what Apple did for good suggestions.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * http://www.halostatue.ca/feed/
* austin@zieglers.ca

Austin Ziegler wrote:
> On 11/20/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
>>
>> 1. Work with the packages as supplied by your distro.
>> 2. *Don't* install the packages supplied by your distro -- use upstream
>> source and put things in /usr/local.
>> 3. Complain and whine to busy people who will blow you off.
>
> 4. Complain to your distro manager to be more sensible when it comes
> to Ruby. Look closely at what Apple did for good suggestions.
>
> -austin

I'm all ears if some one wants to fill me in on what Apple did...

but...

My issue is not with distribution packaging it's with the poor
assumptions that RubyGems makes. It's not that I don't have a dozen
options to work around this. It's that it will never 'just' work until
RubyGems allows for these types of distribution requirements and there's
absolutely no reason it can't.

This latest update some how decided to install rubygems to /usr/local
even though it was previously installed in /usr/lib and it moved it's
gem cache from /var/lib/rubygems to /usr/lib/ruby/gems. Why?

Now I realize the paticular oddities of this are not necessarily
RubyGems problems. I was using the Ubuntu patched version, but I've
looked at that patch and all it did was hardcode the GEM_HOME
environment variable to be /var/lib/rubygems. Why would id decide to
install into /usr/local?

RubyGems has become a core part of Ruby. It needs to just work! As it
is I still can't use it on production servers because I have no
confidence it's not going to going to go mucking around in folders that
don't belong to it.




--
Posted via http://www.ruby-forum.com/.

On Nov 19, 2007, at 21:53 , Michael Greenly wrote:

> I got caught by some "tired at the end of the day" stupidity...
>
> I was using the Ubuntu (apt-get installed) package of RubyGems. Go
> figure if you do a 'gem update --system' in this situation it makes a
> mess of things.
>
> I choose to try gems out this way because every time I've installed
> Gems
> from source to some prefix other than /usr/lib it's managed to find
> some way to not work or be otherwise inconvenient.
>
> RubyGems has really become the one thing about Ruby I dislike.

Rather than using features provided by RubyGems (GEM_PATH), Debian
(and I guess also Ubuntu since it also uses apt) instead chose to
hack RubyGems.

If this causes breakage, I'm sorry, but it is impossible for the
RubyGems team to support a hacked RubyGems.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

On 11/20/07, Michael Greenly <mgreenly@gmail.com> wrote:
> Austin Ziegler wrote:
> > 4. Complain to your distro manager to be more sensible when it comes
> > to Ruby. Look closely at what Apple did for good suggestions.
> I'm all ears if some one wants to fill me in on what Apple did...

Look to posts by Laurent Sansonetti on this list or the rubygems developer list.

> but...
>
> My issue is not with distribution packaging it's with the poor
> assumptions that RubyGems makes. It's not that I don't have a dozen
> options to work around this. It's that it will never 'just' work until
> RubyGems allows for these types of distribution requirements and there's
> absolutely no reason it can't.

There's also absolutely no reason it should. There are plenty of
options if you're having to update a system location, as Eric Hodel
has pointed out in the past.

> This latest update some how decided to install rubygems to /usr/local
> even though it was previously installed in /usr/lib and it moved it's
> gem cache from /var/lib/rubygems to /usr/lib/ruby/gems. Why?

Right. But you installed an *upstream* package (gem update --system)
over a *downstream* package. RubyGems is absolutely *correct* to
assume that I want RubyGems itself to be in the same location as Ruby.
If I want something different (which, frankly, *I* don't) then I have
options available through environment variables. Again, see recent
posts by Eric Hodel for sanctioned options, or Laurent's summary of
Leopard changes to see how you're advised to upgrade RubyGems on
Leopard. It's not "gem update --system", but it's not significantly
harder (I think it's SOME_ENV_VAR=other-location gem update --system).

> RubyGems has become a core part of Ruby. It needs to just work!

Fact: it does.

> As it
> is I still can't use it on production servers because I have no
> confidence it's not going to going to go mucking around in folders that
> don't belong to it.

I don't know why you can't. I'd have no problem using Ruby and
RubyGems on a production server at all.

I'd just never use an Ubuntu package for Ruby or RubyGems. Ever. (Why?
The upstream maintainers at Debian Don't Get Ruby. While the situation
is better than it has been, it's still a freaking nightmare.)

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * http://www.halostatue.ca/feed/
* austin@zieglers.ca

On Nov 20, 2007, at 06:29 , Michael Greenly wrote:
> Rick Denatale wrote:
>> On Nov 20, 2007 12:53 AM, Michael Greenly <mgreenly@gmail.com> wrote:
>>> RubyGems has really become the one thing about Ruby I dislike.
>>>
>>
>> My way of looking a this is the brain-dead packaging of Ruby on
>> debian
>> is the one thing about Ubuntu (and Debian based distros) that *I*
>> dislike.
>>
>> The problems you've experienced, I think, come from trying to mix
>> debian packaged ruby with source installed gems.
>>
>> When I first started using Ruby on Ubuntu I ran into problems like
>> this. At Andy Hunt's suggestion I installed both Ruby and rubygems
>> from source and haven't looked back.
>
> Hardly... in all package managed systems /usr/lib belongs to the
> package
> manager. No other application should ever be mucking around in there.
> This is not something unique to Debian based systems. It's just that
> Debian users tend to be more more vocal about these policies.

Maybe for Linux distributions. RubyGems works on more than just Linux.

> On the other hand if the upstream RubyGems would actually allow for
> the
> concept that it may live in /usr/lib but not be allowed to manipulate
> anything there it would make life a lot easier.

RubyGems allows this via the GEM_PATH and GEM_HOME environment
variables.

It is not the fault of RubyGems if Debian, instead of using the
provided features, partially disables them with hard-coded paths to
get what they want.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

>
> I'd just never use an Ubuntu package for Ruby or RubyGems. Ever. (Why?
> The upstream maintainers at Debian Don't Get Ruby. While the situation
> is better than it has been, it's still a freaking nightmare.)
>
> -austin

That actually made me laugh. Debian doesn't get package managment?
It's really quite the opposite. RubyGems started with a very poor
understanding of living in a package managed world.

In theory it currently has the necessary tools. If --prefix installs
and $GEM_HOME were properly respected there wouldn't be a problem, but
there not!

If they were my stupid 'update --system' mistake wouldn't have moved
ruby gems library from /usr to /usr/local and the gem_home from
/var/lib/rubygems to /usr/lib/ruby/gems.

RubyGems needs to work correctly no matter where Ruby is installed. It
needs to never modify files outside of --prefix (or installed defined
directories) and it needs to consistently respect $GEM_HOME.

--
Posted via http://www.ruby-forum.com/.

On Nov 20, 2007, at 08:18 , Michael Greenly wrote:
> Austin Ziegler wrote:
>> On 11/20/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
>>> 1. Work with the packages as supplied by your distro.
>>> 2. *Don't* install the packages supplied by your distro -- use
>>> upstream
>>> source and put things in /usr/local.
>>> 3. Complain and whine to busy people who will blow you off.
>>
>> 4. Complain to your distro manager to be more sensible when it comes
>> to Ruby. Look closely at what Apple did for good suggestions.
>>
> I'm all ears if some one wants to fill me in on what Apple did...

Apple wanted to integrate RubyGems with Leopard in a manner that was
as invasive as Debian's, but instead of demanding changes, provided
patches with tests.

> My issue is not with distribution packaging it's with the poor
> assumptions that RubyGems makes. It's not that I don't have a
> dozen options to work around this. It's that it will never 'just'
> work until RubyGems allows for these types of distribution
> requirements and there's absolutely no reason it can't.

RubyGems allows for this and has for a long time. GEM_PATH and
GEM_HOME are not new. Even lower-level than that, you can override
values in Config::CONFIG from Ruby to match what you desire and not
need to set GEM_HOME at all.

> This latest update some how decided to install rubygems to /usr/local
> even though it was previously installed in /usr/lib

My understanding of the FHS says that you are not allowed to install
software into /usr/lib, only Debian is allowed to do that. So a hand-
installed (even gem update --system) RubyGems must be installed in /
usr/local.

> and it moved it's gem cache from /var/lib/rubygems to /usr/lib/
> ruby/gems. Why?

Because Debian added a hard-coded hack RubyGems to use /var/lib
instead of using GEM_PATH and GEM_HOME. I don't know why RubyGems is
using /usr/lib/ruby/gems instead of /usr/local/lib/ruby/gems, but I
suspect that Ruby's Config::CONFIG has been partially modified.

> Now I realize the paticular oddities of this are not necessarily
> RubyGems problems. I was using the Ubuntu patched version, but I've
> looked at that patch and all it did was hardcode the GEM_HOME
> environment variable to be /var/lib/rubygems.

Yes, it is regrettable that Debian didn't instead add GEM_HOME to /
etc/profile (or equivalent). In that case (other than the /usr/lib
vs /usr/local/lib problem) upgrading RubyGems would Just Work.

> Why would id decide to install into /usr/local?

My understanding of FHS says that RubyGems must be installed in /usr/
local if you install it by hand.

> RubyGems has become a core part of Ruby. It needs to just work!
> As it
> is I still can't use it on production servers because I have no
> confidence it's not going to going to go mucking around in folders
> that
> don't belong to it.


Set GEM_HOME correctly, and RubyGems will only touch that directory
on install or uninstall.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

On Nov 20, 2007, at 02:33 , Chauk-Mean P. wrote:
> Eric Hodel wrote:
>> RubyGems 0.9.5 adds several new features and fixes several bugs.
>>
>
> RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
> gem.
>
> I just create an issue on the RubyForge tracker :
>
> [#15759] rubygems 0.9.5 cannot install ruby-debug-ide

Thanks.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

On Nov 20, 2007, at 07:14 , Chauk-Mean P. wrote:
> Chauk-Mean P. wrote:
>> Chauk-Mean P. wrote:
>>> Eric Hodel wrote:
>>>> RubyGems 0.9.5 adds several new features and fixes several bugs.
>>>
>>> RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
>>> gem.
>>>
>>> I just create an issue on the RubyForge tracker :
>>>
>>> [#15759] rubygems 0.9.5 cannot install ruby-debug-ide
>>
>> I tried forcing a local installation of ruby-debug-ide-0.1.9.gem and
>> this works :
>> gem install -l ruby-debug-ide
>>
>> It's a bit strange as I have been able to install ruby-debug-base
>> (ruby-debug-base-0.9.3-mswin32.gem) without the local flag (-l).
>
> I think that I have understood what's happening :
> - rubygems 0.9.5 includes dependencies during installation by default
> now
> - when I first install ruby-debug-base locally (without -l), it
> works as
> this gem has no dependency on other gems
> - then when I tried to install ruby-debug-ide locally (again without
> -l), it fails as it seems that rubygems tries to install the required
> dependency (ruby-debug-base) remotely and not locally.
>
> Forcing the local installation with -l solves my problem.
>
> This raises two issues :
> 1- rubygems seems to not take care of gems that are already installed
> (during the dependency checking)

It does for me:

$ gem fetch ruby-debug-base
missing 9371 gems
Bulk updating Gem source index for: http://gems.rubyforge.org
Downloaded ruby-debug-base-0.9.3.gem
[ 15:15 drbrain@kaa:~/tmp ]
$ gem install -l ruby-debug-base -i gems
Installing gem ruby-debug-base-0.9.3
Using local gem /Users/drbrain/tmp/gems/cache/ruby-debug-base-0.9.3.gem
Building native extensions. This could take a while...
Successfully installed ruby-debug-base-0.9.3
1 gem installed
Installing ri documentation for ruby-debug-base-0.9.3...
Installing RDoc documentation for ruby-debug-base-0.9.3...
[ 15:16 drbrain@kaa:~/tmp ]
$ gem install ruby-debug-ide -i gems
Installing gem ruby-debug-ide-0.1.9
Downloading gem ruby-debug-ide-0.1.9.gem
Successfully installed ruby-debug-ide-0.1.9
1 gem installed

If you can reproduce your issue, please file a bug.

> 2- rubygems should try to install dependency gems locally before
> remotely.

Yes, I think this is the core of #15759, so I updated the title.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

Austin Ziegler wrote:
> On 11/20/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
>> Michael Greenly wrote:
>>> Hardly... in all package managed systems /usr/lib belongs to the package
>>> manager. No other application should ever be mucking around in there.
>>> This is not something unique to Debian based systems. It's just that
>>> Debian users tend to be more more vocal about these policies.
>> Let me emphasize what you just said. /usr/lib belongs to the package
>> manager on all distros! There's a *reason* the Ruby source and most
>> other upstream sources install to ("--prefix" in "configure")
>> */usr/local* rather than */usr* by default. So ... your options are
>>
>> 1. Work with the packages as supplied by your distro.
>> 2. *Don't* install the packages supplied by your distro -- use upstream
>> source and put things in /usr/local.
>> 3. Complain and whine to busy people who will blow you off.
>
> 4. Complain to your distro manager to be more sensible when it comes
> to Ruby. Look closely at what Apple did for good suggestions.
>
> -austin

Apple Computer is a for-profit entity. Unless you're buying SuSE/Novell
or RHEL support, I wouldn't count on getting much sympathy from the
distro. I see people from Apple and Microsoft and Sun at RubyConf, but I
don't see people from Gentoo, Debian or Ubuntu, or even Red Hat. If you
were in Charlotte, please speak up and prove me wrong.

I personally think Gentoo is close to optimal in their interaction with
RubyGems, but it gets dicey if you want to use a gem that *isn't* in
Portage. I have multiple Ruby versions on my machines and simply tweak
the PATH and other environment variable settings to get the one I want.

On Mon, 19 Nov 2007 19:35:27 -0500, Eric Hodel wrote:

> RubyGems 0.9.5 adds several new features and fixes several bugs.

Congratulations! I know this is a major step for the Gems team as they
merge their codebase with 1.9... cool beans.

--
Jay Levitt |
Boston, MA | My character doesn't like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm | - Kristoffer

On 11/20/07, Michael Greenly <mgreenly@gmail.com> wrote:
> > I'd just never use an Ubuntu package for Ruby or RubyGems. Ever. (Why?
> > The upstream maintainers at Debian Don't Get Ruby. While the situation
> > is better than it has been, it's still a freaking nightmare.)
> That actually made me laugh. Debian doesn't get package managment?
> It's really quite the opposite. RubyGems started with a very poor
> understanding of living in a package managed world.

Try responding to what was actually written. I said Debian maintainers
Don't Get Ruby. And, to be honest, I question whether they *do* get
package management sometimes. It works well, most of the time, but
they're completely wrong on a number of factors -- mostly because in a
C/C++ binary world, you *have* to do some things certain ways. They're
guilty of a lack of imagination.

> In theory it currently has the necessary tools. If --prefix installs
> and $GEM_HOME were properly respected there wouldn't be a problem, but
> there not!

Yes, they are.

> If they were my stupid 'update --system' mistake wouldn't have moved
> ruby gems library from /usr to /usr/local and the gem_home from
> /var/lib/rubygems to /usr/lib/ruby/gems.

Wrong. RubyGems can't predict when some dumbass maintainer is going to
make an idiotic hardcoded changes. It's certainly **never** going to
be accepted upstream that way.

Your "update --system" problem goes right back to the maintainers, not
RubyGems. At all.