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

[Scott Kitterman]

On Saturday, August 28, 2010 02:58:04 pm Adam Jacob wrote:
> 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

The comparison (at least for Python, I'm not familiar with the others) isn't 
really correct (for Debian/Ubuntu, I don't have other systems to check this 
on).  If I'm using the standard upstream packaging tool (distutils) it 
installs in /usr/local, but in a Python specific directory so the exact concern 
people have expressed about Gems is avoided.

Scott K
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20100903/bca8c70c/attachment-0001.pgp>