[DRE-maint] Bug#448639: +1 for /usr/local

[Adam Jacob]

This has been one of my longest standing issues with Ruby on Debian.

As a systems administrator, having libraries appear in /var/lib/gems,
and binaries in /var/lib/gems/1.8/bin is incredibly confusing.  When I
install a rubygem on a system, I know I'm stepping outside of the
bounds of Debian's purview - I'm not using apt or dpkg, and I'm
venturing into the world of external package management.
Unfortunately, the choice makes it so I loose on two fronts: my
expectation is that things will wind up in /usr/local (as that's what
happens when I use CPAN, pypi, or easy_install), but they don't.
Secondly, unless the maintainer of the application (rails, chef, etc.)
knows the current status of rubygems on Debian and warns me up front,
I have no way of discovering a-priori that the changes to my system
are in /var/lib/gems.

As an active member of the ruby community, I constantly have to caveat
that users on Debian will get a sub-par user experience if they use
the community standard distribution mechanism.  Most often, our advice
is simply to install the upstream rubygems package from source on
every Debian system - so that the behavior they experience at least be
in line with every piece of documentation generated by the ruby
community.  Unfortunately, this has serious drawbacks - Debian policy
exists for a reason, and it makes the user experience better.  In this
case, it makes it significantly worse.  The reputation within the
community is widely that rubygems on Debian is "broken".

As a developer of a popular application built with ruby (Chef,) we
actively maintain and support packages built specifically for Debian.
I think it's clear to everyone that this should be the preferred path
for installation on a Debian machine - it ensures compliance with the
policy, and a smooth and predictable user experience.  In this case
we're talking about what happens when an administrator explicitly
decides to take another route - just like when they use CPAN or pypi.
The reasonable thing to do here is to give them the experience that
they expect, while still keeping the base system clean for the future
- and to me, that means /usr/local.

The comments raised about the possibility of rubygems that install
binaries that replicate common system utilities is true of any outside
package management system, or any random tarball installed on the
system.  We don't alter CPAN, or tar.  Additionally, many rubygems no
longer even ship with setup.rb, and even fewer will as we move to 1.9,
where rubygems is a standard part of ruby.

Please make the defaults be /usr/local.  At the very least, make the
Gem binary path be /usr/locall/bin.

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam at opscode.com