提供本机工具，同时保持最大的可移植性

Question

Twelve-Factor App宣言表示，对于Web应用程序来说，“......与底层操作系统签订了一份清晰的合同，在执行环境之间提供最大可移植性”[强调添加者我]

但是it says：

  

十二因素应用程序也不依赖于任何隐式存在   系统工具。示例包括炮轰ImageMagick或curl。   虽然这些工具可能存在于许多甚至大多数系统上，但却没有   保证它们将存在于应用程序可能运行的所有系统上   未来，或未来系统上的版本是否会发生   与应用程序兼容。如果应用程序需要shell到系统   工具，该工具应该存入应用程序。

并且他们之前已经将“已加入应用程序”定义为：

  

限定在包含应用程序的目录中（称为“vendoring”或   “捆绑”）。

如果（至少在Linux上）原生的64位可执行文件不能在32位环境中运行，那么应该怎么做呢？ - 更不用说在其他操作系统上？或者有更好的方法来处理这个可移植性问题吗？

Answer 1

在我看来，根本不应该。这是因为：

• 如果本机可执行文件是动态链接的，那么它们可能无法仅在未来的OS版本上运行，更不用说未来或过去的处理器架构了。
• 据我所知，通过静态链接本机可执行文件是不可能完全面向未来的。你仍然可以遇到问题。 Solaris甚至不支持系统库的静态链接！
• 库依赖项不是本机工具可以拥有的唯一类型的依赖项。还可能存在其他问题。
• 旧ImageMagick s - 甚至curl - 可能存在安全漏洞，可能会导致您的应用程序遭到入侵。 （这是一个有争议的问题 - 它的有效性取决于你更信任谁来监视/应用安全更新 - 维护和升级服务器的人，或开发人员？当然他们可能是同一个人 - 现在但我的工作假设是服务器最终会应用更新，这反过来又可以保护您的应用免受更新中已修复的系统可执行文件中的安全漏洞的影响。）

我的观点：如果您选择的依赖关系管理系统只是无法处理本机可执行文件，请在README中添加注释并完成它。如果您没有自述文件，请创建一个。并且（对于内部Web应用程序）将您需要的本机工具添加到您在设置服务器时使用的标准服务器映像或脚本，并确保另外记下为什么它们在那里

Answer 2

这只是意味着您应该在您的销售资源之间拥有声明性依赖关系和清晰的合同。

如果您的应用程序依赖于特定版本的软件，则必须与其签订一份干净的合同，以便您可以模拟/存根开发功能。此外，即使在Windows中，也不可能将依赖关系管理作为应用程序的一部分（尽管您可能希望它发生在安装程序而不是应用程序本身）。

如果你的产品非常依赖于其他软件，即使在测试环境中它也无法运行，那么它必须捆绑在一起，你必须制定出EULA，或者你真的没有一个产品。