在Debian上与rubygems有什么关系？这是不同的和奇怪的

我已经注意到Debian上的 rubygems至少存在以下奇怪之处(在我的情况下为5.0 lenny)：

>包进入不同的安装位置：/ var / lib / gems vs /usr/lib / ruby​​ / gems
> debian包是rubygems 1.3.6,并且将rubygems更新到最新版本(1.3.7)不起作用：

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

>并非所有宝石看起来都像在其他系统上那样工作.例如,在安装Phusion Passenger时,即使它已经安装好,也没有检测到“架子”宝石.
>使用源tarball手动安装rubygems并重新安装我的所有宝石(到/usr/lib / ruby​​ / gems)使我的问题消失了.

这是怎么回事？为什么debian的包装有所不同？

解决方法

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

[编辑：最迟在Debian 7中已经过时了.]

混合到两个不同的包管理器通常是一个非常糟糕的主意. Debian-Ruby团队尽力修补RubyGems,使其成为一个稍微不那么糟糕的想法.

此外,Debian有一套旨在保持系统一致的规则. RubyGems也有自己的一套规则.遗憾的是,这两套规则不兼容.因此,Debian-Ruby开发人员修补RubyGems以尊重Debian的规则,而不是RubyGems的规则.将/usr/lib / ruby​​中的gem移动到/ var / lib就是其中之一.

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

通常,您应该避免混合包管理器.要么将RubyGems用于所有东西(在这种情况下最好是从源代码安装RubyGems而不是使用Debian软件包)或者使用APT来处理所有事情,在这种情况下你可能会对DebGem这个服务感兴趣,这是Phusion的一个服务(Ruby的制造商) Enterprise Edition和Phusion Passenger)为几乎所有的Gems提供Debian和Ubuntu软件包.