[DRE-maint] Bug#448639: Debian Bugs information: detailed logs for Bug#448639

[Tim Olsen]

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