我正在进行跨平台开发，我想为Linux构建一个漂亮的，自包含的（！）包。我知道这不是通常的方式，但应用程序需要在一个地方的所有数据，所以我将它安装到/ opt，就像许多其他专有软件包一样。我最终将提供deb和rpm包，但现在只有.tar.gz。用户应该在某处提取它，它应该工作。我宁愿没有安装人员。
首先是我的问题，然后是细节：
现在有一些细节：这是我的项目（为此我称之为 foo ）布局：
现在在包中，将有两个额外的元素：
libs 将包含项目所需的所有共享库， foo.sh 是一个将LD_LIBRARY_PATH设置为包含 libs 的脚本。因此，用户将执行 foo.sh ，程序应该启动。
我有一个shell脚本，它按以下步骤打包软件：
你怎么看待这个？这种方法存在一些问题：
你是怎么做到的？
修改 刚出现的另一个问题：您如何确定您的软件所依赖的库？我做了一个 ldd foo ，但是有很多。我看了一下WorldOfGoo包的外观，它们只发送了很少的库。如何假设用户系统中存在哪个库，哪个库不存在？只需将所有目标分布安装到虚拟matine中，看看需要什么？
答案 0 :(得分：5)
将您的东西（带有依赖库）打包到/opt的方法是如何打包专有（甚至是开源）软件。建议使用Linux基金会（请参阅my answer to the other question了解链接）。
外部库可以从头编译并嵌入到构建过程中作为单独的步骤（特别是如果您修改它们），或者从某些发行版的包中获取。第二种方法更容易，但第一种方法允许更大的灵活性。
请注意，没有必要在包中包含一些非常低级的库（例如glibc，Xorg）。他们最好留给系统供应商调整，你可能只是假设它们存在。此外，还有Linux Standard Base，它记录了最重要的图书馆;这些库几乎无处不在，并且可以信任。
另请注意，如果您在较新的系统下进行编译，则很可能旧系统的用户将无法使用它，而反之则不然。因此，为了获得更好的兼容性，在比现在早两年的系统下编译包可能是有用的。
我刚刚概述了一些通用的东西，但我相信Linux Developers Network网站包含有关打包和便携性的更多信息。
根据我在开源分发项目中看到的内容，您的脚本与分发供应商打包软件的方式相同。他们的脚本自动修补源代码，模仿软件安装并将生成的文件夹打包成DEB和RPM。
Tar.gz或者课程也可以使用，但是创建一个RPM并不复杂，你错过了这样一个机会，让你的用户生活变得更加轻松。
回答你的问题，
是的，您必须对依赖项进行两次硬编码。
问题是，当您在CMake中对它们进行强制转换时，您可以使用其他术语来指定它们，而不是在打包脚本中指定它们。 CMake是指共享库和头文件，而打包脚本是指包。
包名称与共享库和标头之间没有交叉分布的一对一关系。它因分布而异。因此，应该指定两次。
但是分发供应商可以轻松地重新打包该程序包，特别是如果您努力将所有依赖的lib打包到其中（因此对端口的外部依赖性会更少）。此外，一个可以将包从一个发行版移植到另一个发行版的工具很快就会出现（我会在发布时更新我的答案）。
是的，您必须指定两次版本。
但问题是，您可以按照软件包和软件版本永远不会失去同步的方式组织您的打包过程。只需将包装脚本从您的存储库中检出（或从您的网站下载）与脚本将写入包规范的版本完全相同。
要分析软件的依赖关系，您可以使用我们的开源免费Linux Application Checker工具。它将报告它所依赖的库列表，显示与您的软件兼容的发行版，并帮助您的应用程序在各个发行版中更具可移植性。事实证明，有时可以通过一点点努力实现更多的交叉分发兼容性，并且您不必将自己锁定为仅支持几个选定的发行版。
答案 1 :(得分：0)
长期思考（或询问您的产品开发部门）您需要支持哪些发行版/架构。
确保他们完全理解测试的含义。
我希望您能提供一份支持的发行版和架构的简短列表。
这实际上取决于哪些客户为Linux支持付费。大多数人使用Redhat Enterprise（在服务器上）或Centos（从技术角度来看难以区分）。
如果你只需要支持Redhat，你只需要支持RPM，这是一个很好的工作。