跨 Linux 发行版分发二进制应用程序

发布于 2024-08-02 03:12:18 字数 241 浏览 5 评论 0原文

我编写了一个应用程序,但到目前为止还不是开源的,我想在各种 Linux 发行版上分发可执行文件。 执行此操作的最佳方法是什么,我稍微研究了一下 .rpm 和 .deb 打包,但我找不到它是否可以用于二进制文件。 理想情况下,我想要类似 OS X 上的 PackageMaker 或 Windows 上的常规安装程序,将其自动复制到 /usr/bin 中。 这就是 .rpm 和 .deb 软件包的用途吗?还是我必须捆绑一个能够自动执行此操作的 shell 脚本?

I've written an application which as of yet is not open source and I'd like to distribute the executable across various linux distros. What's the best way to do this, I've looked a little bit at .rpm and .deb packaging but I can't find if that can be used for binaries or not. Ideally I'd like something like the PackageMaker on OS X or a regular installer on windows that will have it automatically copy into /usr/bin. Is that what .rpm and .deb packages are for or do I have to bundle a shell script that will do it automatically?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

合久必婚 2024-08-09 03:12:18

RPM 和 DEB 包是 Linux 中分发二进制包的两种主要机制。 RPM 用于 RedHat 及其衍生产品(Fedora、CentOS),而 DEB 用于 Debian 和 Ubuntu。

.rpm 和 .deb 文件本身通常是“哑”档案,并通过预安装的帮助应用程序安装到文件系统中的正确位置。 您不必担心编写脚本来安装文件,除非它是一个非常复杂的应用程序,需要特殊的每系统配置。

我看到的分发二进制文件的常见模式是:

  • 发布压缩的 tarball(.tar.gz 或 .tar.bz2),并让分发打包者担心细节。 这对于流行的应用程序来说效果很好,但如果它是新发布的,没有人会足够关心你的应用程序来打包它。
  • 以 tarball 形式发布,加上 RPM 和/或 DEB 软件包(取决于客户需求)。 拥有受支持发行版的客户可以安装预制软件包。 无论如何,任何使用不寻常发行版的人都可能很乐意从 tarball 安装。

RPM and DEB packages are the two primary mechanisms for distributing binary packages in Linux. RPM is used by RedHat and its derivatives (Fedora, CentOS), while DEB is used in Debian and Ubuntu.

The .rpm and .deb files themselves are generally "dumb" archives, and are installed to the correct locations in the filesystem by pre-installed helper applications. You don't have to worry about writing scripts to install files, unless it's a very complicated application which needs special per-system configuration.

The usual patterns I see for distributing binaries are:

  • Release a compessed tarball (.tar.gz or .tar.bz2), and let distribution packagers worry about the details. This works well for popular applications, but if it's newly released, nobody will care enough about your application to package it.
  • Release as a tarball, plus RPM and/or DEB packages (depending on customer needs). Customers with a supported distribution may install the pre-made package. Anybody who's using an unusual distribution is probably happy to install from a tarball anyway.
魂牵梦绕锁你心扉 2024-08-09 03:12:18

MojoSetup 是一个用户友好的、完美的跨发行版解决方案,并且经过良好许可( zlib,非常宽容)。 它所需要的只是任何 Linux 发行版附带的标准 sh shell。 它还允许通过创建 freedesktop.org 规范快捷方式以简单的方式创建桌面快捷方式,几乎所有 Linux 图形环境都支持这些快捷方式(因此只需以不同分辨率转储为 PNG 并填充 .desktop 文件的空白)。

安装程序使用非常简单的 Lua 编程语言编写脚本,并且有几个示例安装程序脚本 Mercurial 存储库 以及冗长的教程。 还有很多年的时间来支持其发展成为轻量级跨发行版安装程序。

MojoSetup is a user-friendly, perfectly cross-distro solution and nicely-licensed (zlib, very permissive). All it requires is the standard sh shell which comes with any Linux distribution. It also allows for desktop shortcuts the easy way by creating freedesktop.org spec shortcuts, which are supported by just about all graphical environments for Linux (so just dump in a PNG at different resolutions and fill in the blanks of the .desktop file).

Installers are scripted using the very simple Lua programming language and there are several example installer scripts in the Mercurial repository as well as a lengthy tutorial. There are also many years to back up its development into a lightweight cross-distro installer.

电影里的梦 2024-08-09 03:12:18

rpm 和 deb 将存储二进制文件。 您很可能需要为每个发行版或发行版变体提供不同的二进制文件,因为在不同的发行版上,事情是不同的,例如路径。

我建议从 rpm 和 deb 两个版本开始,然后钉住这两个发行版。 然后,也许可以为其他发行版制作一个 tarball,让人们可以自己提取目录结构、复制和处理权限。

另外,对于 deb 之类的东西,您可以将站点设置为存储库。 这使得人们可以轻松地在 ubuntu 中添加存储库并获取/安装 deb。 许多第三方闭源开发人员都这样做。

The rpm and deb will store the binaries. You'll need to have a different binaries for each distro or distro variant most likely, just because on different distros things are different like paths.

I recommend starting with the two you have rpm and deb and nail those two distro. Then maybe do a tarball for misc distros have people can extract and directory structure and copy and handle permissions on their own.

Also, for things like deb you can setup a site as a repository. That makes it easy for people to add the repo and get/install the deb in ubuntu very easily. A lot of 3rd party closed source devs do that.

如何视而不见 2024-08-09 03:12:18

这就是 .rpm 和 .deb 文件的作用,但您必须确保安装发行版能够处理 .rpm 和 .deb 文件。 如果您想要确定的东西可以跨多个发行版运行,而您无法确定它们是否有正确的包管理器,那么您几乎必须求助于 shell 脚本方法。 我建议,如果你能摆脱它,为 .rpm 和 .deb 构建二进制文件 - 这样,你就可以覆盖大部分发行版,并且允许用户以某种方式安装它们很舒适且熟悉,您不必尝试编写自己的安装程序/卸载程序 shell 脚本。

That's what .rpm and .deb files do BUT you have to be sure that the installee distro has the ability to deal with the .rpm and .deb files. If you want something that's sure to run across multiple distros, where you can't be sure that they will have the right package manager, then you pretty much have to resort to the shell script method. I would advise, if you can get away with it, building your binary for both .rpm and .deb - this way, you get most of the distros covered, and you allow users to install in a way they are comfortable and familiar with, and you don't have to try to roll your own installer / uninstaller shell scripts.

旧街凉风 2024-08-09 03:12:18

您可能应该为您正式支持的每个 Linux 发行版提供一个本机包(因为您正式支持它们,所以您将在它们上进行测试,因此这样做应该很简单),并提供一个人们可以直接下载的 .tar.gz其他的。

用户始终可以为某些您不支持的外来发行版制作自己的 .rpm 等; 但他们不能向你抱怨,除非它不能在官方支持的操作系统上运行。

你们正式支持哪些操作系统? 显然,您需要对所有这些进行测试(至少,您需要在每个版本的每个操作系统上通过所有回归测试套件)。

如果您支持多种架构,这当然会很复杂。

You should probably provide a native package for each Linux distribution that you officially support (as you officially support them, you'll be testing on them so doing this should be trivial), and provide a .tar.gz which people can drop in for other ones.

Users can always make their own .rpm etc for some alien distribution which you don't support; but they can't complain to you unless it doesn't work on an officially supported OS.

Which OSs do you officially support? You'll obviously need to test on them all (at the very least, you'll need to pass all your regression test suite on each OS on each release).

This is of course complicated if you support multiple architectures.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文