打包Linux专用软件

打包Linux专用软件 通用问题

打包（带有相关库）

/opt

内容的方法是打包专有（甚至是开源）软件的方式。这是Linux
Foundation的推荐做法。

外部库既可以从头开始编译，也可以作为一个单独的步骤（尤其是如果您对其进行了修改）嵌入到您的构建过程中，也可以从某些发行版的软件包中获取。第二种方法比较容易，但是第一种方法具有更大的灵活性。

请注意，没有必要在软件包中包含一些真正的底层库（例如glibc，Xorg）。他们最好留给系统供应商进行调整，而您可能只是假设它们存在。此外，还有一个Linux标准库，其中记录了最重要的库。这些库几乎无处不在，并且可以信任。

还要注意，如果您是在较新的系统下编译，则很可能旧系统的用户将无法使用它，反之则不然。因此，为了达到更好的兼容性，在比今天早两年的系统下编译软件包可能会很有用。

我只是概述了一些通用的内容，但是我相信Linux Developers
Network网站包含有关打包和可移植性的更多信息。

打包

从我在开放源代码分发项目中看到的内容来看，您的脚本以与分发供应商打包软件相同的方式进行 *** 作。他们的脚本会自动修补源代码，模拟软件安装并将结果文件夹打包到DEB和RPM中。

当然，Tar.gz也可以工作，但是例如创建RPM并不足够复杂，以至于您错过了使用户生活变得如此轻松的机会。

回答您的问题，

• 是的，您必须对依赖项进行两次硬编码。

事实是，当您在CMake中对它们进行加固时，可以使用其他术语来指定它们，而不是在打包脚本中指定它们时。CMake是指 共享库 和 头文件
，而打包脚本是指 软件包 。

程序包名称与共享库和标头之间没有交叉分布的一对一关系。它随分布而变化。因此，应指定两次。

但是，发行版供应商可以很容易地重新打包该软件包，尤其是当您努力将所有相关的lib打包到其中时（这样对port的外部依赖性就会减少）。另外，一个可以将软件包从一个发行版本移植到另一个发行版本的工具将很快出现（发布时我将更新我的答案）。

• 是的，您必须指定两次版本。

但事实是，您可以以一种 打包和软件版本永远不会同步
的方式来组织打包过程。只需使打包脚本从您的存储库中签出（或从您的网站下载），就与该脚本将写入包装规范的版本完全相同。

分析依赖

要分析软件的依赖性，您可以使用我们的开放源代码，免费的Linux Application Checker工具。它将报告它所依赖的库列表，显示与您的软件兼容的发行版，并帮助您的应用程序在各个发行版之间更具可移植性。事实证明，有时只需付出很少的努力就可以实现更多的跨发行版兼容性，而您不必将自己锁定在仅支持少数几个发行版的支持上。