什么'；Debian和rubygems的交易是什么？它'；It’不一样，很奇怪

我注意到Debian上的rubygems（我的例子是5.0 lenny）至少有以下奇怪之处：

• 软件包进入不同的安装位置：/var/lib/gems vs/usr/lib/ruby/gems
• debian软件包是rubygems 1.3.6，将rubygems更新到最新版本（1.3.7）不起作用：

$sudo gem更新--系统 错误：执行gem时。。。（运行时错误） gem更新——系统在Debian上被禁用。RubyGems可以通过aptitude或apt get使用官方Debian存储库进行更新。

• 并不是所有的gem都像其他系统一样工作。例如，在安装Phusion Passenger时，它没有检测到“机架”gem，即使它确实已安装
• 使用源tarball手动安装rubygems并重新安装所有gems（to/usr/lib/ruby/gems）使我的问题得以解决

---

怎么回事？为什么debian的软件包有所不同？

请注意，我在下面写的内容最近发生了重大变化。DebianRuby团队或多或少地彻底改进了他们的整个方法，包括但不限于RubyGems的打包。我不确定Debian 6，但在之后的版本中，从Debian安装Ruby和RubyGems包应该是安全的，甚至可能是推荐的。很明显，这也将渗透到Ubuntu中

---

[编辑：以下内容最迟在Debian 7中过时。]

混合使用两个不同的包管理器通常是一个非常糟糕的主意。DebianRuby团队尽最大努力修补RubyGems，使其成为一个稍微不那么糟糕的想法

此外，Debian还有一套旨在保持系统一致性的规则。RubyGems也有自己的一套规则。不幸的是，这两套规则不兼容。因此，Debian Ruby开发人员修补RubyGems以尊重Debian的规则，而不是RubyGems的规则。将gems从

/usr/lib/ruby

移动到

/var/lib

就是其中之一

另一个问题是Debian是稳定的。这意味着Debian团队保证整个系统（所有20000个包）的行为在发布期间不会改变。但是RubyGems开发人员不会单独提供他们的错误修复，获得错误修复的唯一方法是升级到一个新版本，具有（可能）不同的行为。因此，Debian Ruby开发人员不能不修改RubyGems源代码，他们必须对1.3.7中的错误修复进行反向工程，并将其应用到1.3.6版本中，以确保向后兼容性

---

通常，您应该避免混合使用包管理器。任何东西都可以使用RubyGems（在这种情况下，最好从源代码处安装RubyGems，而不是使用Debian软件包），或者任何东西都可以使用APT，在这种情况下，您可能会对Phusion guys（Ruby Enterprise Edition和Phusion Passenger的制造商）提供的服务感兴趣它为几乎所有的Gems提供了Debian和Ubuntu软件包。

如果你想管理自己的ruby环境，我可以看看。让不同的环境满足您的开发需求是一个很好的方法，因为让debian包管理全局ruby env更明智。

避免其不同和奇怪的最好方法是从源代码安装它。（许多人建议在任何情况下都这样做。）

对于1.9.2以后的版本，从源代码安装Ruby非常容易。这让你的宝石和其他一切，自动，完全集成。（例如，安装了Rails gem后，您可以键入'ri field_For'以了解Rails中嵌套表单的所有信息。）

---

无论是否使用RVM，它现在都是获得Ruby的最简单、最可靠的方法。无论如何，我的10c。

这并没有回答原始问题的任何部分。我认为答案是肯定的——我的观点是，它不必是不同的和奇怪的。编辑了我的答案，使之更清晰。问题是关于预构建的Debian包。从源代码和RVM编译与这个问题无关。好吧，如果我们要挑三拣四，那么“这是怎么回事…”就成了一个相当模糊的问题，不是吗？这不是很“实际和负责”。因此，我选择了一个切实可行的方法来解决这些奇怪的问题。我不认为那是件坏事。 $ sudo gem update --system ERROR: While executing gem ... (RuntimeError) gem update --system is disabled on Debian. RubyGems can be updated using the official Debian repositories by aptitude or apt-get.