[Rubygems-developers] Gem binary clash problems.
neil at brightbox.co.uk
Tue Aug 5 03:41:57 EDT 2008
There is a problem with the way that gem installs binaries, in that it
doesn't really co-operate with the native package manager or other
versions of itself when it installs and uninstalls binaries. This
leads to clashes.
If the native package manager has installed '/usr/bin/rails' then gem
will overwrite it.
If you install and uninstall a gem, but don't remove the executable
gem will leave a dangling wrapper that fails with:
`report_activate_error': Could not find RubyGem brightbox (>= 0)
from /usr/local/lib/site_ruby/1.8/rubygems.rb:134:in `activate'
from /usr/local/lib/site_ruby/1.8/rubygems.rb:49:in `gem'
This means that shell scripts that just check whether a command exists
or not before running them will fail as well.
If instead you decide to remove the binary then you run into the
gem1.8 install <mygem>
gem1.9 install <mygem>
gem1.8 uninstall -x <mygem>
<mygem_binary>: command not found
And if you don't uninstall a version then you are into the
philosophical argument of whether the first 1.8 version or the last
1.9 version of the gem should be the one called by <mygem_binary>.
In Debian/Ubuntu these are solved using the operating system's
alternatives system and I've used that in my Rubygems packaging to
work around the problems described above. There is a feeling though
that Rubygems really ought to be dealing with this problem itself.
Clearly it is only going to get worse as users switch between MRI,
Rubinius and Jruby.
I couldn't see an easy way of getting this inside Rubygems, and
neither is it as simple a problem as it first seems (to handle it
properly needs a lot of state work - if the inside of the Debian
alternatives scripts are anything to go by).
I was wondering what others thought about how these clashes should be handled?
More information about the Rubygems-developers