gem vs apt-get在服务器环境中

我不使用apt-get，因为我运行NetBSD，但“pkgsrc”与apt-get具有相似的作用。

我的本地政策很简单。 如果我可以使用gem，我使用gem。 如果我不能，我从pkgsrc得到它。 一些需要本地代码（sqlite等）的东西根本就不能可靠地安装成gem。

我看到使用gem的主要好处是，我可以同时安装多个版本。 例如，我安装了3个不同版本的Rails，应用程序可以慢慢地从一个移植到另一个。

我不确定如果apt-get会让你这样做，但我知道pkgsrc不。 这是我需要和使用的function。

需要记住的一点是，使用gem更新将比使用官方存储库更快。 也许有更新的第三方存储库，我不确定。 不过，我的印象是，如果你需要先进的新鲜事物，那就用gem来更新。

我们的政策是，当依赖链中没有“下游”的时候，我们使用gem（通常是客户部署和托pipe的代码），但是我们自己做的每一件事都是正确的打包的，所以我们会把所有依赖的gem放到代码库去满足那些依赖关系。 不同的包装系统不应该是一个问题; 您的系统pipe理自动化工具应该能够优雅地处理这些差异。

我在更新的时候在沙子上划线，稳定就好了

例如，我部署在hardy，如果Ruby 1.8.6是可以接受的，否则，最新发布的Ubuntu，如果我需要1.8.7

然后我安装rubygems tarball，因为你需要接近Rails 2.3.4的最新版本，然后用gem安装乘客等。

rmagick等情况下，你需要有imagemagick安装，我使用系统debs for imagemagick，然后安装rmagickgem

从gembuild设debs可以自动化。 Python，OCaml，Cabal和CPAN包很简单。 debgem是25K软件包的gem-to-deb服务，但它似乎并没有起飞，而是滞后了几次rails版本。

“ 在build立一个服务器来托pipe乘客+ Apache的铁轨上使用apt-get和gem时，我应该在哪里画线？ 它甚至重要吗？ 在考虑软件更新等时，将包pipe理系统混合使用感觉不对。 »

请注意，APT（其中“apt-get”是其中的一部分） 不是包pipe理器，而是依赖pipe理器。 这个非常重要; 包pipe理器是DPKG。

现在规则是，一组目录应该只包含一组由一个包pipe理器pipe理的包，否则将会发生非常糟糕的事情（例如，由一个包pipe理的包将被部分覆盖而不被另一个包pipe理的包警告） 。

RubyGem是像DPKG这样的包pipe理器，或者像Perl的CPAN或者Python的EasyInstall下载器一样，不应该和其他包pipe理器混合，包括DPKG。

“ 我看到使用gem的主要好处是，我可以同时安装多个版本。 »

DPKG不能安装同一个软件包的不同版本或不同平台是一个非常严重和不好的限制，这使得Debian创build了非常丑陋和糟糕的解决方法（在软件包名称本身编码版本和平台）。 不幸的是，select使用DPKG的人必须忍受这个限制。

如果从我以前的答复中不清楚，

“ 把包pipe理系统混合起来感觉不对

将它们混合在同一个子树中的确是错误的。 如果你通过给他们不同的子树安装两个包pipe理系统（例如DPKG和RubyGems），那就好了。 这就是为什么“/ usr / local”是一个单独的子树，“/ opt”是另一个单独的子树。 RubyGems默认使用'/ usr / local / lib / ruby​​'，这对我来说似乎是合理的（并且不会与DPKG冲突，但可能会与手动安装的软件包相冲突）。

“ 一次安装多个版本。 »

如果这是一个需求，那么在上面提到的一个单独的子树中使用RubyGems。 DPKG就像你想的那样简直不能以任何体面的方式做到。 这里的比较是在RubyGems和DPKG之间进行的，而不是在你的问题或我以前的答案中没有提到的RPM，即使一些Debianistas似乎对RPM有自卑感。

有一个库或应用程序的多个版本是一个非常重要的function，尤其是testing与生产使用，特别是对于Web应用程序，所以我会build议RubyGems，而不是使用debgems.org。

这可能是你看到50/50分的那些问题之一。 也许你应该更准确地定义你的标准来得到一个有用的答案。

根据我的经验，所有基于nix的软件包pipe理器（例如ports，macports，rpms，dpkgs等）都有相当奇怪的相互依赖关系，并且经常安装你不想要或不需要的东西，或者不需要安装你需要的东西。 我没有看到与gem或CPAN软件包相同的模式。