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: a...@opscode.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
