[Rubygems-developers] Installing Rubygems in User's Local Directory to fix Gem on Memory-Limited Systems

Randy Parker randy.j.parker at gmail.com
Thu Jun 7 15:30:17 EDT 2007

Which bug is not fixed yet?  I see that [rubygems #8470] is still open on   http://rubyforge.org/tracker/?atid=575&group_id=126&func=browse 

But my understanding of #8470 is that the the local
dir is not _automatically_ used for installation.
Do you mean that the most recent note posted to the bug
report, which proposes a workaround by re-running
the install sequence 

  ruby setup.rb config --prefix=$GEM_HOME
  ruby setup.rb setup
  ruby setup.rb install

Is also known NOT to work?  (it ain't just me?)

If that is true, then is it accurate to say that there is no way
to run "gem update --system" for a "non-standard installation directory"
(that is, one that doesn't require root access, as described by   http://rubygems.org/read/chapter/15#page101 )

If there is no workaround, then because "gem install" / "gem update" require rubygems-update- to run on memory-constrained hosting containers,
and the only way to install it is with root permission, then it must be that
nobody can use "gem" unless they have a dedicated system (or a hosting
container that is as big as a dedicated system).

Surely I'm missing something?

On 6/7/07, Eric Hodel < drbrain at segment7.net> wrote:
On Jun 7, 2007, at 10:27, Randy Parker wrote: 

> [...]
> After some searching, I found [rubygems #8470] gem update --system
> should take the prefix at which rubygems is installed into
> accountwhich advises
> To workaround, switch to the downloaded rubygem update (  e.g.
> GEM_HOME/gems/rubygems-update-0.9.2/), then run the install sequence
> again:
> But in all cases the install step insisted on trying (and naturally
> failing) to install to the hosting computer's system dir, with the 
> same line as included above:
> setup.rb:633:in `initialize': Permission denied - /usr/local/bin/
> gem (Errno::EACCES)
> Why is it attempting to install to the system when I'm telling it 
> not to?

Because the bug hasn't been fixed yet, and nobody's looked into
fixing it.

Note that the bug may be in setup.rb, which will take a bit of
figuring out.  Its quite the monster.
Poor workers blame their tools. Good workers build better tools. The
workers get their tools to do the work for them. -- Syndicate Wars

Rubygems-developers mailing list 
Rubygems-developers at rubyforge.org


More information about the Rubygems-developers mailing list