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.
_______________________________________________
Rubygems-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rubygems-developers
