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
signature.asc
Description: This is a digitally signed message part.
