[DRE-maint] Bug#448639: Debian Bugs information: detailed logs for Bug#448639
Tim Olsen
tim at brooklynpenguin.com
Mon Aug 30 16:58:38 UTC 2010
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
More information about the Pkg-ruby-extras-maintainers
mailing list