我使用Vagrant和VirtualBox为我们的产品设置了可重复的构建环境。我们的目标是RHEL7,Oracle7和Ubuntu 14.我已经阅读了一些RPM构建指南,但有一点我不清楚。以RHEL6为例,假设我在RHEL 6.4上构建了一个rpm,但想要确保6.0和6.0以上的兼容性。生成的RPM是否与整个RHEL 6系列兼容,还是我需要在6.0上构建才能确保?兼容RPM RPM构建环境
基本上,我试图决定是否应该让Vagrant将系统更新到我的rpm构建环境中的最新次要版本和软件包。
我使用Vagrant和VirtualBox为我们的产品设置了可重复的构建环境。我们的目标是RHEL7,Oracle7和Ubuntu 14.我已经阅读了一些RPM构建指南,但有一点我不清楚。以RHEL6为例,假设我在RHEL 6.4上构建了一个rpm,但想要确保6.0和6.0以上的兼容性。生成的RPM是否与整个RHEL 6系列兼容,还是我需要在6.0上构建才能确保?兼容RPM RPM构建环境
基本上,我试图决定是否应该让Vagrant将系统更新到我的rpm构建环境中的最新次要版本和软件包。
我一直在假设兼容性保证是从系列中的任何地方到系列中的任何地方,但我至少见过一个实例被破坏(我不知道这是否意外或不)。
因此,为了安全起见,我可能会建议使用您正式要支持的系列的最早版本。
一般来说,只要你只依赖公共接口。确定一个公共接口是什么,并不是那么容易。
从Red Hat Enterprise Linux: Application Compatibility GUIDE
在一个主要版本的生命周期中,红帽使得商业 合理的努力来维护所有次要版本和勘误公告的核心 运行环境的二进制兼容性。
这是您看起来最好的保证。编辑:另请参见Red Hat Enterprise Linux Application Compatibility Policies
在RHEL 5.x和6.x期间,我们已经构建了许多项目,其中的二进制文件在较旧的次版本上运行, 我没有看到任何问题。 (虽然这些应用程序的二进制接口是最小的,但仅限于libc/libstdC++和其他3-4个库以及一些python程序)
(作为一个方面说明,如果您正在构建内核模块,内核将提供否ABI保证,并可能在次要版本之间进行更改。)