RVM is great. But by design it's a solution to compiling software on every machine. This simply doesn't work for lots of sysadmins, especially with lots of machines - it means installing a complete build environment which opens up much more evil.

Well, yes. And that's the effective situation we've got at the moment.

What I'm proposing is a full acknowledgement of that: if you want to live on the bleeding edge, then that should be supported as well as possible, but a very clear delineation should be drawn between the responsibilities of the distribution and those of the developer/sysadmin. RVM does that very cleanly, even if you only use it with the system ruby.

"If rubygems itself is a library dependency, package it but take away the gem command."

Might be better to un-gem any required gems and package them with the app. Then add some code that fakes out any calls in the app to 'gem' or 'rubygems'.

OTOH, rubygems is part of ruby now, so leaving it out might be a problem.

If you bundle one gem with five different apps (as could easily happen with, say, rack), then any security updates to that gem mean that five distro security updates have to get pushed out. That's a lot more work than it needs to be.

As far as calls to the "gem" method go, I have in mind a distro-specific replacement which would check that the right system package is installed instead of the right gem. That would, I think, be handy for packagers.

Having rubygems the library being part of ruby is not something I can see a problem with. Having the gem command available is a problem because it overlaps so much with functionality which should be provided by the distro. That being said, ~/.gem is useful; maybe it should only be neutered for root/sudo.