[Rubygems-developers] Gem binary clash problems.

Eric Hodel drbrain at segment7.net
Wed Aug 13 17:57:28 EDT 2008

On Aug 5, 2008, at 00:41 AM, Neil Wilson wrote:
> 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.

Yes.  Perhaps it should ask.

> If you install and uninstall a gem, but don't remove the executable
> gem will leave a dangling wrapper that fails with:
> /usr/local/lib/site_ruby/1.8/rubygems.rb:578:in
> `report_activate_error': Could not find RubyGem brightbox (>= 0)
> (Gem::LoadError)
>       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.

I'm not sure what the utility of the option to keep the wrapper is.   
RubyGems should be smarter here.

> 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>
> <mygem_binary>: command not found

--format-executables is provided for this purpose, but it is a rare  
need.  Most users of RubyGems have only one ruby installed.

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

I think it's ok for users to shoot themselves in the foot, but  
RubyGems would definitely be more friendly if it asked first.

> 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?

I think making a few changes to when RubyGems overwrites executables  
will help a lot, primarily by asking the user about what to do, and  
advertising about --format-executables at that time.

More information about the Rubygems-developers mailing list