On 08/30/2010 11:46 AM, Clint Byrum wrote: > rubygems is not an end user tool, it is a development tool. As such, > it has sharp jagged edges that let you do things like this. I'm all > for making sure users are protected from themselves, but gaining root > privileges means you are taking responsibility for your actions, meaning > you should read through the docs of the the things you're running and > understand the gems you're installing.
I am a developer and being able to switch between Ruby 1.8 and Ruby 1.9.1 gems is important for me. For example, I use Rubygems-installed rake to run my automated tests. All I have to do to see if my tests work on a different version of Ruby is to update my PATH. Making sure that a Ruby library works for both Ruby 1.8 and 1.9 is an important activity for a Ruby library developer nowadays. One minor point: you do not need to be root to modify /usr/local. On default Debian installs (but not in Ubuntu), you only need to be in the staff group. > > Its cool that right now there's no conflict between 1.8 and 1.9 installed > gems. I'm sure its saved a few users from themselves. However, it has > confused many, many more users and left the ruby dev community frustrated, > so while I see the merit in leaving it as it is, I see more merit in > changing it. > As a Ruby library developer, installing Ruby gem executables in /usr/local/bin would frustrate me more because it would be more difficult to test on both Ruby 1.8 and Ruby 1.9. Besides, I'm not convinced that using /usr/local is itself FHS-compliant. (I've sent an email earlier about this but I haven't seen it go through yet). If upgrading the rubygems package may modify /usr/local then that violates the FHS: "It needs to be safe from being overwritten when the system software is updated." Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
