[Rubygems-developers] Gem binary clash problems.

Neil Wilson 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'
       from /usr/bin/brightbox:18

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
opposite problem.

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?

Neil Wilson

More information about the Rubygems-developers mailing list