我正在做跨平台开发，我想为 Linux 构建一个漂亮的、独立的 (!) 包。我知道这不是通常的做法，但应用程序需要将所有数据集中在一个位置，因此我将其安装到 /opt 中，就像许多其他专有软件包一样。我最终会提供 deb 和 rpm 包，但目前只是 .tar.gz。用户应该将其提取到某个地方并且它应该可以工作。我宁愿没有安装程序。
首先是我的问题，然后是细节：
- 其他人如何为 Linux 打包专有软件？
- 是否有用于打包软件（包括共享库）的工具？
现在了解一些细节：这是我的项目（我称之为foo为此目的）布局：
现在，在包中，将有两个附加元素：
libs将包含项目所需的所有共享库，并且foo.sh是一个设置 LD_LIBRARY_PATH 以包含的脚本libs。因此，用户将执行foo.sh并且程序应该启动。
我有一个 shell 脚本，按以下步骤打包软件：
- 创建空目录并将 foo.sh 复制到其中
- 调用构建过程并进行安装进入新目录
- 从文件系统复制共享库
- 将所有内容打包为 .tar.gz
你觉得这怎么样？这种方法存在一些问题：
- 我必须对所有依赖项进行两次硬编码（一次在 CMake 中，一次在打包脚本中）
- 我必须定义版本号两次（一次在源代码中，一次在打包脚本中）
你怎么做呢？
Edit:刚刚出现的另一个问题：如何确定您的软件依赖哪些库？我做了一个ldd foo，但是数量非常多。我查看了 WorldOfGoo 软件包的外观，它们只提供很少的库。我如何假设哪些库将出现在用户系统上，哪些不会出现？只需将所有目标发行版安装到虚拟 matine 中，看看需要什么？
一般问题
将你的东西（带有依赖库）打包到/opt这就是专有（甚至开源）软件的打包方式。 Linux 基金会推荐的做法（请参阅我对另一个问题的回答用于链接）。
外部库可以从头开始编译并作为单独的步骤嵌入到构建过程中（特别是如果您修改它们），也可以从某些发行版的包中获取。第二种方法更容易，但第一种方法具有更大的灵活性。
请注意，没有必要将一些非常低级的库（例如 glibc、Xorg）包含到您的包中。它们最好留给系统供应商来调整，您可能只是假设它们存在。此外，还有一个Linux 标准库，记录了最重要的库；这些库几乎无处不在，并且值得信赖。
另请注意，如果您在较新的系统下编译，很可能旧系统的用户将无法使用它，反之则不然。因此，为了获得更好的兼容性，在比现在早两年的系统下编译软件包可能会很有用。
我只是概述了一些通用的东西，但我相信Linux 开发者网络网站包含有关包装和便携性的更多信息。
包装
根据我在开源分发项目中看到的情况来看，您的脚本的执行方式与分发供应商打包软件的方式相同。他们的脚本自动修补源代码、模拟软件安装并将生成的文件夹打包到 DEB 和 RPM 中。
当然，Tar.gz 也可以，但是创建 RPM 之类的东西还不够复杂，您不会错过这样一个让用户的生活变得更加轻松的机会。
回答您的问题，
-
是的，您必须对依赖项进行两次硬编码。
问题是，当您在 CMake 中对它们进行硬编码时，您可以使用其他术语来指定它们，而不是在打包脚本中指定它们。 CMake指的是共享库 and 头文件，而打包脚本指的是packages.
包名称与共享库和标头之间不存在跨发行版的一对一关系。它因发行版而异。因此，应指定两次。
但是发行版供应商可以轻松地重新打包该包，特别是如果您努力将所有依赖库打包到其中（因此需要移植的外部依赖项会更少）。此外，一种可以将软件包从一个发行版移植到另一个发行版的工具很快就会出现（我将在发布时更新我的答案）。
-
是的，您必须指定您的版本两次。
但问题是你可以这样组织你的包装过程：软件包和软件版本永远不会不同步。只需使打包脚本从您的存储库中签出（或从您的网站下载）与脚本将写入包规范的版本完全相同即可。
分析依赖关系
要分析您的软件的依赖性，您可以使用我们的开源、免费Linux 应用程序检查器工具。它将报告它所依赖的库列表，显示您的软件兼容的发行版，并帮助您的应用程序在各个发行版之间更加可移植。事实证明，有时只需付出很少的努力就可以实现更多的跨发行版兼容性，并且您不必将自己锁定在仅支持少数选定的发行版上。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
