"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.
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.