Forum: Ruby-core [Ruby 1.9 - Bug #5060][Open] Executables in bin folder conflict with their gem versions.

Issue #5060 has been reported by Vit Ondruch.

----------------------------------------
Bug #5060: Executables in bin folder conflict with their gem versions.
http://redmine.ruby-lang.org/issues/5060

Author: Vit Ondruch
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: 1.9.3


It would be nice if the executables for rdoc, rake, ri, etc. locate in 
bin folder, would be standard RubyGems stubs. Otherwise, once there is 
installed version of such library as a gem, the original file is 
rewritten and the functionality of bundled library is lost.

But my main concern is the conflict between ruby and gem executables, 
since it makes packaging for Linux distributions hard (for Fedora and 
RHEL in my case).

Issue #5060 has been updated by Yui NARUSE.

Status changed from Open to Assigned
Assignee set to Eric Hodel
Target version set to 1.9.x


----------------------------------------
Bug #5060: Executables in bin folder conflict with their gem versions.
http://redmine.ruby-lang.org/issues/5060

Author: Vit Ondruch
Status: Assigned
Priority: Normal
Assignee: Eric Hodel
Category:
Target version: 1.9.x
ruby -v: 1.9.3


It would be nice if the executables for rdoc, rake, ri, etc. locate in 
bin folder, would be standard RubyGems stubs. Otherwise, once there is 
installed version of such library as a gem, the original file is 
rewritten and the functionality of bundled library is lost.

But my main concern is the conflict between ruby and gem executables, 
since it makes packaging for Linux distributions hard (for Fedora and 
RHEL in my case).

Issue #5060 has been updated by Eric Hodel.

Status changed from Assigned to Closed

Since I committed r32608 and r32611 I think this issue is now invalid.

If a different version of rake or rdoc are installed they will behave 
the same as the bundled library.  rake _0.9.2.1_ will load the built-in 
version of rake, for example.  If a newer version of RDoc were installed 
rdoc and ri would behave the same.

I'm closing this ticket unless differing behavior can be reproduced.
----------------------------------------
Bug #5060: Executables in bin folder conflict with their gem versions.
http://redmine.ruby-lang.org/issues/5060

Author: Vit Ondruch
Status: Closed
Priority: Normal
Assignee: Eric Hodel
Category:
Target version: 1.9.x
ruby -v: 1.9.3


It would be nice if the executables for rdoc, rake, ri, etc. locate in 
bin folder, would be standard RubyGems stubs. Otherwise, once there is 
installed version of such library as a gem, the original file is 
rewritten and the functionality of bundled library is lost.

But my main concern is the conflict between ruby and gem executables, 
since it makes packaging for Linux distributions hard (for Fedora and 
RHEL in my case).

Issue #5060 has been updated by vo.x (Vit Ondruch).

Status changed from Closed to Assigned

Sorry, I'm reopening, but the issue is still present.

When you install Ruby, it carries initial version of /usr/bin/rdoc [1] 
(I picked up the RDoc as an example, but it is valid also for Rake, 
etc). Now let's assume that you will install updated RDoc, which 
replaces the file with the typical RubyGems stub, something like:

$ cat /usr/bin/rdoc
#!/usr/bin/ruby
#
# This file was generated by RubyGems.
#
# The application 'rdoc' is installed as part of a gem, and
# this file is here to facilitate running it.
#

require 'rubygems'

version = ">= 0"

if ARGV.first
  str = ARGV.first
  str = str.dup.force_encoding("BINARY") if str.respond_to? 
:force_encoding
  if str =~ /\A_(.*)_\z/
    version = $1
    ARGV.shift
  end
end

gem 'rdoc', version
load Gem.bin_path('rdoc', 'rdoc', version)


Now, this is problem for packaging systems, namely RPM (but I would be 
surprised if that is not issue for DEB as well). If you will do 
monolithic Ruby package, which provides /usr/bin/rdoc and later you want 
to package independent updated version of RDoc gem, which provides 
/usr/bin/rdoc as well, you are in conflict, since the files are 
different. If they would be the same (and there is no reason to be 
different IMO), there would be no conflict. The file would be own by two 
packages in parallel, which is supported scenario.

So what I'd like to see is the RubyGems stub in /usr/bin, especially 
after you committed r32608.

Actually, I'm trying to put together some proposal to solve #5481 and 
#6124, which might fix also this issue.

Thank you.





[1] https://github.com/ruby/ruby/blob/trunk/bin/rdoc
----------------------------------------
Bug #5060: Executables in bin folder conflict with their gem versions.
https://bugs.ruby-lang.org/issues/5060#change-27328

Author: vo.x (Vit Ondruch)
Status: Assigned
Priority: Normal
Assignee: drbrain (Eric Hodel)
Category:
Target version: 2.0.0
ruby -v: 1.9.3


It would be nice if the executables for rdoc, rake, ri, etc. locate in 
bin folder, would be standard RubyGems stubs. Otherwise, once there is 
installed version of such library as a gem, the original file is 
rewritten and the functionality of bundled library is lost.

But my main concern is the conflict between ruby and gem executables, 
since it makes packaging for Linux distributions hard (for Fedora and 
RHEL in my case).

Issue #5060 has been updated by drbrain (Eric Hodel).

Target version changed from 2.0.0 to next minor

This is too risky to fix for 2.0.0, sorry I did not have time.
----------------------------------------
Bug #5060: Executables in bin folder conflict with their gem versions.
https://bugs.ruby-lang.org/issues/5060#change-36413

Author: vo.x (Vit Ondruch)
Status: Assigned
Priority: Normal
Assignee: drbrain (Eric Hodel)
Category:
Target version: next minor
ruby -v: 1.9.3


It would be nice if the executables for rdoc, rake, ri, etc. locate in 
bin folder, would be standard RubyGems stubs. Otherwise, once there is 
installed version of such library as a gem, the original file is 
rewritten and the functionality of bundled library is lost.

But my main concern is the conflict between ruby and gem executables, 
since it makes packaging for Linux distributions hard (for Fedora and 
RHEL in my case).