商业软件应该使用哪些安装程序类型来支持 Linux?

Mik*_*ray 9 linux packaging software-installation

源代码未开放或免费,因此安装时编译不是一种选择。到目前为止,我已经看到开发人员:

  • 提供一个 tar.gz 文件,用户可以在合适的位置解压缩。
  • 提供带有 install.sh 脚本的 .tar.gz 以运行基本安装程序,甚至可能提示用户输入安装选项。
  • 提供 RPM 和/或 deb 文件,允许用户继续使用他们熟悉的本地包管理工具来安装/升级/卸载。

希望支持最多数量的 Linux 发行版,让用户的生活尽可能轻松,同时也尽可能少地维护构建/打包/安装程序基础设施。

寻找有关如何打包我的软件的建议。

War*_*ung 19

我看到了两种看待它的方式。

一种是针对最流行的 Linux,为每个 Linux 提供本机软件包,并按流行顺序提供软件包。几年前,这意味着首先为 Red Hat 类型的 Linux 提供 RPM,然后随着时间的推移为每个不太流行的基于 RPM 的 Linux 重建源 RPM。这就是为什么 Mandriva RPM 通常比 Red Hat 或 SuSE RPM 旧一点的原因。不过,随着 Ubuntu 在过去几年如此流行,您可能希望从 .deb 开始,然后再添加 RPM。

另一种方法是尝试同时针对所有Linux,这正是提供二进制 tarball 的人所尝试的。作为系统管理员和最终用户,我真的不喜欢这个选项。此类 tarball 将文件散布在您将它们解压缩的整个系统中,并且以后无法进行诸如卸载、包验证、智能升级等细节的选择。

您可以尝试一种混合方法:最流行的 Linux 的本机包,加上奇怪的 Linux 和老派系统管理员的二进制 tarball,无论出于何种原因都不喜欢包管理器。

  • 制作一个可移植的二进制 tarball 可能比你想象的要多得多。一个潜在的陷阱是 g++ ABI 在过去几年中发生了多次变化,因此您可能必须发布您使用的任何 C++ 库的二进制版本,而不是使用平台版本来实现足够广泛的兼容性。这是单个二进制 RPM 不能在任何地方安装和运行的原因之一。然而,RPM 似乎在文化上接受了这一事实,而 tarball —— 可能是因为它们是一个古老的标准 —— 预计可以在任何地方使用。 (2认同)