更新
原谅我的无知，当我真正指的是 RubyGems 时，我想我问了他关于 rvm 的问题。而且我认为他正在考虑 RubyGems，因为它似乎确实存在一些争议，至少在过去有：http ://stakeventures.com/articles/2008/12/04/rubygem-is-from-mars- aptget-is-from-venus。所以请 s/rvm/RubyGems/g 回答以下问题。
结束更新
我的服务器管理员对在 Debian 上使用 rvm 有点警惕。他是这样说的：
不幸的是，整个 rvm 系统无法与像 Debian 这样的打包系统正确交互，而且当您在不同时间进行部署时，部署是一场噩梦。[你可以很容易地在不同的系统上使用不同版本的模块，等等，你必须处理整个 Debian 打包系统中的 rvm stomping。]
我认为他在这里所说的是我们将在多台服务器上运行应用程序，如果我们升级一台服务器，它将给我们带来严重的问题。
有没有办法解决他的顾虑？
RVM 绝不会在 debian 软件包系统上形成或形成“踩踏”。RVM 为普通用户安装在 $HOME/.rvm 中，或者在 /usr/local/rvm 中使用必须添加成员的“rvm”组，这是第 3 方非关键任务应用程序的正常位置，标头, 和图书馆。
由于包管理器，RVM 应运而生。他们永远搞砸了红宝石和宝石的依赖关系，落后于立即推出安全更新的时代，在同一个盒子上安装和管理多个红宝石，而无需玩符号链接游戏来让它们工作，并进行部署对具有多个不同部署要求的多台机器来说是一场噩梦。
RVM 以一种非常无缝的方式解决了所有这些问题，它不仅着眼于确保安装和使用它的用户的安全性，而且还确保包管理器不参与其中。这确保了包管理工具及其已安装包的数据库不会突然被破坏。
我作为用户参与其中，然后作为 RVM 项目的开发人员参与其中，因为它很好且优雅地解决了这个难题。
Rubygems 不允许很好地控制 gem 版本，但与 bundler 一起使用它可以比 apt-get 更好地控制版本。
您需要阅读Bundler - 它允许您指定松散的依赖关系，Gemfile而严格的依赖关系记录在Gemfile.lock.
他担心ruby 是一个移动的目标，ruby 每隔几个月就会更新一次，所有用户都应该始终更新到最新的补丁级别。
Ruby 有很多不同的包（可能除了 openssl），其中 ruby 团队正在使用补丁更新版本，这允许将安全工作集中在一个地方，但这与包管理器的保守方法相反，即选择一个版本并且只应用安全补丁对它来说，听起来很稳定——它将安全工作分散到多个团队并减慢了整个开源社区的速度。操作系统维护人员不想接受有人为他们完成部分工作并且他们可以信任某人的事实。
至于您的管理员表现出很多无知的过程的重复性，RVM 允许锁定版本，这与上面解释的 Ruby 方法背道而驰。因此，锁定所有内容的最简单方法是将 RVM 锁定到一个版本：
rvm install 1.15.14
但是，如果需要锁定 RVM，首选方法是将其锁定到保持兼容性但提供更新的次要版本：
rvm install latest-1.15
RVM 不会让这个版本持续很长时间，但是任何时候都会担心当前稳定的“稳定性”——我们会更新以前的版本，以便您决定使用哪个版本。
@deryldoucette 在他的回答中也解释了很多，我试图不“重新解释”事情。