打包用于Linux的专有软件 [英] Packaging proprietary software for Linux

问题描述

我正在跨平台开发，我想为Linux构建一个漂亮的，自包含的(！)软件包.我知道这不是通常的方式，但是应用程序需要将所有数据集中在一个地方，因此我将其安装到/opt中，就像许多其他专有软件包一样.我最终将提供deb和rpm软件包，但目前仅是.tar.gz.用户应将其提取到某处，并且应该可以工作.我宁愿没有安装程序.

I'm doing cross-platform development and I want to build a nice, self-contained (!) package for Linux. I know that that's not the way it's usually done, but the application requires all data in one place, so I'm installing it into /opt, like many other proprietary software packages do. I will eventually provide deb and rpm packages, but it will only be .tar.gz for now. The user should extract it somewhere and it should work. I'd rather not have an installer.

首先是我的问题，然后是详细信息:

First my questions, then the details:

1. 其他人如何为Linux打包专有软件?
2. 是否有用于打包软件(包括共享库)的工具?

现在了解一些详细信息:这是我的项目的布局(为此我将其称为 foo ):

Now for some details: This is my project's (I call it foo for this purpose) layout:

• foo(二进制)
• config.ini
• 数据

现在，包装中将包含两个附加元素:

Now in the package, there will be two additional elements:

• 库
• foo.sh

libs 将包含项目所需的所有共享库，而 foo.sh 是一个脚本，用于将LD_LIBRARY_PATH设置为包括 libs .因此，用户将执行 foo.sh 并且程序应启动.

libs will contain all the shared libraries the project requires, and foo.sh is a script that sets LD_LIBRARY_PATH to include libs. Therefore, the user will execute foo.sh and the program should start.

我有一个Shell脚本，可按以下步骤打包软件:

I have a shell script that packages the software in the following steps:

1. 创建一个空目录并将foo.sh复制到其中
2. 调用构建过程并将进行安装到新目录中
3. 从文件系统复制共享库
4. 将所有内容打包为.tar.gz

1. Create empty directory and copy foo.sh to it
2. Invoke the build process and make install into the new directory
3. Copy shared libs from the filesystem
4. Package everything as .tar.gz

您如何看待?这种方法存在一些问题:

What do you think of this? There are some problems with this approach:

• 我必须对所有依赖项进行两次硬编码(一次在CMake中，一次在打包脚本中)
• 我必须两次定义版本号(一次在源代码中，一次在打包脚本中)

你如何做到的?

修改: 刚刚出现的另一个问题:如何确定软件依赖哪个库?我做了一个 ldd foo ，但是有很多事情要做.我查看了WorldOfGoo软件包的外观，它们仅提供了很少的库.我该如何假设哪个库将出现在用户的系统上，而哪个库则不会呢?只需将所有目标发行版安装到虚拟机中，看看有什么要求?

Another question that just came up: How do you determine on which libraries your software depends? I did an ldd foo, but there's an awfull lot. I looked at how WorldOfGoo packages look, and they ship only very few libraries. How can I make assumptions about which library will be present on a user's system and which won't? Just install all targeted distributions into a virtual matine and see what's required?

推荐答案

一般性问题

将您的东西(带有相关库)打包到/opt的方法是打包专有(甚至是开源)软件的方式.这是Linux Foundation的推荐做法(请参见我的回答另一个问题以获取链接).

Generic issues

Your way to package your stuff (with dependent libs) to /opt is how proprietary (and even open-source) software is packaged. It's recommended practice of The Linux Foundation (see my answer to the other question for links).

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

External libs may be either compiled from scratch and embedded into your build process as a separate step (especially if you modify them), or fetched from packages of some distributions. The second approach is easier, but the first one allows more flexibility.

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

Note that it's not necessary to include some really low-level libraries (such as glibc, Xorg) into your package. They'd be better left to system vendors to tune, and you may just assume they exist. Moreover, there's an Linux Standard Base, that documents the most important libraries; these libraries exist almost everywhere, and can be trusted.

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

Note also that if you compile under a newer system, most likely, users of older systems won't be able to use it, while the reverse is not true. So, to reach better compatibility, it might be useful to compile package under a system that's two years older than today.

我只是概述了一些通用的东西，但是我相信 Linux开发者网络网站包含有关打包的更多信息.和便携性.

I just outlined some generic stuff, but I believe that Linux Developers Network website contains more information about packaging and portability.

从我在开源发行项目中所看到的来看，您的脚本的执行方式与发行商打包软件的方式相同.他们的脚本会自动修补源代码，模拟软件安装并将结果文件夹打包到DEB和RPM中.

Judging by what I saw in the open-source distribution projects, your script does it the same way distribution vendors package software. Their scripts automatically patch sources, mimic installation of software and package the resultant folders into DEBs and RPMs.

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

Tar.gz, or course, could also work, but creating, for example, an RPM is not complex enough for you to miss such an opportunity to make life of your users so much easier.

回答您的问题，

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

• Yes, you have to hard-code dependencies twice.

问题是，当您在CMake中对它们进行硬编码时，您可以使用其他术语来指定它们，而不是在打包脚本中指定它们时. CMake指的是共享库和头文件，而打包脚本指的是包.

The thing is that when you hardocde them in CMake, you specify them in the other terms than when you specify them in a packaging script. CMake refers to shared libraries and header files, while packaging script refers to packages.

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

There's no cross-distribution one-to-one relationship between package names and shared libs and headers. It varies through distributions. Therefore, it should be specified twice.

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

But the package can be easily re-packed by distribution vendors, especially if you strive to packing all dependent libs into it (so there'll be less external dependencies to port). Also, a tool that can port packages from one distribution to another will appear soon (I'll update my answer when it's released).

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

Yes, you have to specify your version twice.

但是事实是，您可以采用以下方式组织打包过程:打包版本和软件版本永远不会不同步.只需使打包脚本从您的存储库中签出(或从您的网站下载)，使其完全符合该脚本将写入包装规范中的版本即可.

But the thing is that you may organize your packaging process in such a way that package and software versions never get out-of-sync. Just make the packaging script check out from your repository (or download from your website) exactly the same version that the script will write to package specifications.

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

To analyze dependencies of your software, you may use our open-source, free Linux Application Checker tool. It will report the list of libraries it depends on, show distributions your software is compatible with, and help your application be more portable across distributions. It turns out that sometimes more cross-distribution compatibility can be achieved by little effort, and you don't have to lock yourself into support of just a few selected distributions.

这篇关于打包用于Linux的专有软件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！