什么是一般规则，决定何时从官方的.deb软件包存储库安装软件包，而不是使用语言的软件包管理器进行安装？上游存储库中的软件包经常至少稍微过时，但我也不想让我的软件包与“官方”软件包发生冲突，而且似乎aptitude在许多情况下都会强制我安装官方软件包。
3个回答
这个问题很难一概而论地回答。
官方的.deb软件包提供了稳定性和由Ubuntu社区提供的全面支持。如果你不需要最新版本，可能使用这个解决方案更好。你还可以通过软件包管理器获取更新、卸载等支持。
如果你需要来自上游的支持，或者需要最新的功能，最好从发行系统（如CPAN、gem、pear等）获取。
官方的.deb软件包提供了稳定性和由Ubuntu社区提供的全面支持。如果你不需要最新版本，可能使用这个解决方案更好。你还可以通过软件包管理器获取更新、卸载等支持。
如果你需要来自上游的支持，或者需要最新的功能，最好从发行系统（如CPAN、gem、pear等）获取。
- txwikinger
1
...而且您希望保留跟踪更新、安全修复等责任。 - lfaraone
在我（虽然经验有限）的经验中，专门针对某种语言的软件包管理器在跟踪超出该语言范畴的依赖关系方面远不如.deb软件包管理器做得好（我特别指的是对C编码库的依赖关系，这些库被软件包用于Python、Perl、Ruby等语言）。
举个例子，如果一个Pypi Python软件包“barfoo”需要某个名为“libfoobar”的库来构建“_bf.so” Python扩展模块，并且需要“libfoobar”至少是5.2版本，那么你就需要自己找到哪个“.deb”软件包提供了适合的“libfoobar”版本（如果Pypi软件包与上游的最新版本保持紧密追踪，你可能找不到合适的版本）——并且在以后卸载“barfoo”时要记住它（这样“libfoobar”供应商就会变成“孤立”的，可以/应该被删除）。
我不认为将Pypi/CPAN等与其他软件包分发系统集成的问题已经可以被视为“解决”了。为了最小化管理困扰，如果您只需要一个官方的.deb文件（不需要最新和最大的功能等），我认为这是可行的；当然，对于一些您想要保持最新更新的软件包（例如，您是软件包的上游作者/维护者之一;-)，有一个选项是在软件包使用的任何版本控制系统（svn，hg，git，bazaar，...）中保持一个新的仓库并从源代码构建。Pypi/CPAN等处于“中间地带”。肯定有时候这种折中的方式也是可行的。
而且，一个可以考虑的选项是自己构建一个
举个例子，如果一个Pypi Python软件包“barfoo”需要某个名为“libfoobar”的库来构建“_bf.so” Python扩展模块，并且需要“libfoobar”至少是5.2版本，那么你就需要自己找到哪个“.deb”软件包提供了适合的“libfoobar”版本（如果Pypi软件包与上游的最新版本保持紧密追踪，你可能找不到合适的版本）——并且在以后卸载“barfoo”时要记住它（这样“libfoobar”供应商就会变成“孤立”的，可以/应该被删除）。
我不认为将Pypi/CPAN等与其他软件包分发系统集成的问题已经可以被视为“解决”了。为了最小化管理困扰，如果您只需要一个官方的.deb文件（不需要最新和最大的功能等），我认为这是可行的；当然，对于一些您想要保持最新更新的软件包（例如，您是软件包的上游作者/维护者之一;-)，有一个选项是在软件包使用的任何版本控制系统（svn，hg，git，bazaar，...）中保持一个新的仓库并从源代码构建。Pypi/CPAN等处于“中间地带”。肯定有时候这种折中的方式也是可行的。
而且，一个可以考虑的选项是自己构建一个
.deb软件包（基于Pypi/CPAN/&c或者上游源代码），并保留这些软件包的仓库（对于那些你发现官方.deb仓库太少或者过时的软件包）。这不比其他方式安装麻烦多少（手动跟踪语言外的依赖），而且有助于识别“孤立软件包”等问题（此外，如果你发布你的打包工作，还可以帮助其他人;-)）。- Alex Martelli
我一直反对使用Aptitude来管理来自另一个软件包管理器的软件包。CPAN、Gems、Pecl、Pear等都是各自语言的软件包管理器。根据我的观点，你应该首选它们，因为它们就是为此而设计的。更不用说现在大多数这些管理器都能处理升级和更新了（比如gem update、gem upgrade等）。就好像在Ubuntu机器上使用yum来安装Apache一样。
话虽如此，确实有少数情况下Aptitude版本更胜一筹。其中一个情况是从语言包管理器安装模块失败时（通常是由于配置问题不同），我很少遇到这个问题，但当我遇到时，Aptitude中的相应软件包可以解决问题。
在我看来，优先选择语言包管理器 > Aptitude。
- Marco Ceppi