在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,但在版本之后,从Debian中安装Ruby和RubyGems包应该是安全的,甚至建议.显然,这也将逐渐渗透到Ubuntu中.

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

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

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

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

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