有人做过依赖管理吗？

Question

我使用过各种依赖关系管理工具来安装软件:自制软件、阴谋工具、规则宝石等等。尽管有人为安装他们的软件包提供了简单的指导，但有时软件包管理器无法解决依赖关系，安装也会失败。这种情况比应该发生的情况更为普遍。而且令人沮丧！最后，您将尝试对安装过程进行故障排除，我认为用户(即使他们是开发人员)不应该这样做。

这是人们敲Linux的原因之一(我喜欢！)与Windows相比，安装可能与复杂问题相关联。Windows用户不需要编译源代码。

有人知道依赖管理工具(或依赖管理策略)在消除与安装相关的凸起方面特别成功吗？显然，一些包管理人员必须比其他人更好。还是这仍然是一个未解决的问题？

Answer 1

由于在野外发布软件的内在问题，软件包管理器无法安装一些软件:它可以安装在任何地方，并且应该适应不同的机器、不同的硬件、不同版本的操作系统、不同的配置、不同的并行软件和不同的问题。

您可以在自2008年发布的所有Debian、Ubuntu、Fedora、Red和SUSE发行版上测试您的软件，您的持续集成服务器在每次提交时都会部署150多个不同版本和变体的OSes，并具有不同的配置。

然后，当你的产品最终发布时，它似乎在乔的机器上不幸地失败了，因为Joe有一个自定义编译的罗马尼亚Debian，缺少一些你认为总是安装的软件包，硬盘驱动器不时挂起30秒，没有鼠标，并且有一个在罗马尼亚流行的杀毒软件，而且只有在那里才流行。

现在，他在一个受欢迎的论坛上发布了一条信息，告诉我们你的软件崩溃了，因为你根本不知道你的CI中应该有一个罗马尼亚的VM，它有一个自定义编译的Debian，它模拟了一个濒临死亡的硬盘，没有鼠标，还有一些未知的杀毒软件。

依赖关系管理工具，如用于Debian类型发行版的apt-get、用于Node.js的npm或用于Python的pip，在系统中发挥了很大的作用。有时候，您通过它们安装包而它不能工作，这并不是这些系统的错误，而更多的是开发人员(和安装程序)的错误。不要将单个包的故障归咎于依赖关系管理工具。

安装是否更容易出错？是。有些事情你可以做，使你的生活更容易。所有这些要点都至关重要。

1. 经常使用官方支持的OSes并进行升级(但不要跳转到最新的前阿尔法级)。事实上，您可以在Windows 2000上安装一些软件，这并不意味着您应该安装一些软件。
2. 使用最新的硬件和最新的驱动程序。来自旧主板或旧GPU或过时驱动程序的问题是巨大的。当我开始使用Ubuntu时，我讨厌Chromium:它每天崩溃几次，常常迫使整个系统崩溃。更新GPU驱动程序解决了这个问题。
3. 不要试图安装您在系统上找到的所有软件包。我的意思是，如果您的公司服务器充当域控制器、DNS和DHCP，并在其上有Sharepoint服务、IIS (最好是两个版本并排入侵，同时支持PHP和Python )、SQL server (它意外地占用了所有RAM)、SMTP和十几个其他服务，那么您应该从解雇您的系统管理员开始。
4. 设置保安。任何人都不应该通过远程桌面访问您的公司服务器来“微调一件小事”。
5. 将您的配置置于版本控制之下。您应该能够在几分钟内从一堆脚本中以无人参与的方式创建任何机器的副本。如果您必须安装这个，那么，然后配置这个东西并将这个文件移动到那个文件夹中，您就会犯错误，这将付出很大的代价(除非您能够为您的整个基础设施提供一个星期的停机时间)。
6. 在生产前先测试第三方软件。代理服务器的3.0版本发布了吗？太棒了。让我们在准备阶段中配置它，在生产服务器的精确副本上运行自动化测试，并确保一切按预期工作。是吗？我们现在可以升级生产服务器了。
7. 严格地虚拟化。VM更容易处理和复制。“您可以在不到一分钟的时间内引导VM”，它可以非常容易地为测试目的部署一些东西，查看它是否工作，对它进行实验，或者在它失败时抛出VM。真正的，非虚拟机是伟大的，当你需要尖端的性能和VM抽象成为瓶颈。但是在真正的机器槽PXE上安装一个发行版可能需要15分钟，有时甚至更长。这使得实验变得更加困难。
8. 分隔严重。如果您有DNS服务和SMTP服务器，请运行两个VM。如果您托管了两个Python应用程序，而且它们太小，每个应用程序都不需要一个专用的VM，那么virtualenv就是您的朋友。
9. 严重自动化。应该自动部署VMs。软件应该自动推送到VM上。软件和基础设施应自动测试。任何手工操作都会引入随机，难以跟踪和复制错误，以及缓慢的过程。
10. 快照有帮助。在生产中安装一些东西，却没有时间对所有东西进行深思熟虑的测试？不要忘记创建磁盘的快照，以便在几秒钟内恢复到工作版本，如果有任何问题发生。

旁注与问题无关:你的第二段与其说是事实，不如说是你的个人观点。我破坏Windows的原因是，与我在Windows上搜索软件网站、搜索下载按钮(主要是因为未知的原因)、搜索下载按钮(主要是因为未知的原因而隐藏的)相比，使用apt-get install (考虑到大多数情况下它的工作时间)要容易得多，然后尝试安装软件，最后花一个小时配置它，因为默认配置对任何人来说都是无法使用的。

Answer 2

请注意，包管理器太多了；人们一直认为这是一项简单的任务，并重新发明了方向盘。根本的问题是软件可以以意想不到的方式进行交互。

大多数具有版本依赖关系的打包系统从“大于或等于”开始：

progX v2.8 requires libfoo >= v1.1

然后有人发布libfoo2.0，它改变了接口并破坏了progX。因此，现在progX的开发人员决定使用精确的依赖关系：

progX v2.9 requires libfoo == v2.0

然后在libfoo中发现了一个安全漏洞，每个人都应该紧急升级！但是确切的依赖性阻止了这一点；包管理器要么卸载progX，要么拒绝升级。

您可能认为可以通过同时安装libfoo1.1、libfoo2.0和libfoo2.1来避免这种情况。这主要是可行的，只要它们都可以保存在不同的目录中，您就不会介意磁盘空间的消耗，而且它们也不必将文件放在某个公共位置。但是，如果库可以依赖其他库，这将失败:很少有语言/系统允许您将libfoo1.1和libfoo2.0链接到同一个程序中。

另一种解决方案是将所有依赖项打包到progX中。这是Windows、安卓和iOS采用的方法。除了操作系统及其库之外，您没有其他外部依赖项。这并不完美(“这个应用程序不能在你的手机上工作，因为它需要更新的Android，而你的制造商不会升级”，也没有自动的安全升级)，但是你基本上把故障点的数量减少到了一个。

我不熟悉您提到的阴谋集团，但这似乎是同样的基本问题：https://www.fpcomplete.com/user/simonmichael/how-to-cabal-install & https://hackage.haskell.org/package/cabal-nirvana暗示它是由于需要其他包的不兼容版本的包造成的。

这可能需要一个社会解决方案，协调软件包的发布，以避免这个问题。Apt之所以奏效，是因为Debian的协调和发布策略确保了它的存在，而Ubuntu在此基础上，在一个单一雇主的领导下与一小群聪明的员工建立了联系。

(我感到失望的是，函数式编程社区的依赖解决能力很差，因为它是FP人员和工具应该擅长的一类数学图形问题。他们应该看看apt/dpkg，看看它如何处理这个问题。)