一个地方有很多不同的人有不同的显著计算实施和在大型企业中，组织利用了Linux的挑战需要，是...的包装。
认真。包装是一个大问题。
举个例子:
假设你负责一个1000人的组织。您的服务器需要说明您需要(或至少可能需要)一个带有某种付费支持协议的面向服务器的Linux发行版。很容易。您可以选择Red Hat Enterprise或SUSE Linux Enterprise。服务器需求的满足。
但是市场部呢?企业级的、以服务器为中心的发行版对它们都有意义吗?可能不会。也许您可以标准化其中一种媒体产品—以发行版为中心—或者您已经为服务器选择的企业发行版的社区驱动方面。
无论哪种方式，你的包的版本可能不同。也许一点点。可能很多。强迫你，如果你想有任何标准化的水平在整个组织上的特定应用程序的版本（比如，你的办公套件和网络浏览器），以维持至少你已经这样选择的两个Linux发行版之一的定制库远（如果不是两个）。
然后，当系统管理员、软件开发人员和测试人员想要使用他们想要使用的任何发行版时，会发生什么?有没有试过告诉程序员他必须使用特定操作系统的特定版本?如果有更快捷的方法来彻底发动叛乱，我从来没见过。因此，现在您的组织中可能已经安装了Debian、Ubuntu、Mint、openSUSE和Fedora。
加上一个人跑拱门和/或Gentoo的谁只是不会再提醒您的是建筑/ Gentoo的是最好的。我们都知道那家伙。
你会怎样做？保持每一个软件公司依赖于（可能是一个可怕的很多）的Linux半打不同分布的资料库？
那要做很多工作。可能工作量很大。但是另一种方法是对组织中每个人使用的每个工作站的单一发行版进行标准化。对很多人来说，这不是一个选择。
因此，维护包多个发行，它是！
为多个Linux发行版维护包的2个选项
在我看来，只有两个真正的方法去这个（没有要疯了）：
第一个是完全跳过传统的包装，使用一种交叉分发的应用程序包格式——值得注意的是，AppImage要么FlatPak。
按照这种方式，理论上您可以打包一个支持大多数现代发行版的AppImage(它本质上是一个自运行的.iso，包含在任何受支持的Linux变体上运行特定应用程序所需的所有资源)。
或者你可以坚持传统的包装和独特的每个发行库，而利用类似的打开构建服务跨所有这些发行版自动构建这些包(以及自动维护存储库)。
两者都有优缺点。从您只需要构建一个“包”的角度来看，构建AppImage是很简单的—不需要了解各种发行版的打包格式。但另一方面，这并没有解决确保所有工作站都是最新的问题。
坚持使用传统的存储库和包格式可以解决更新问题。这是事实。但是您需要更多地了解交叉分发打包。即使在使用诸如Open Build Service(它使这一切变得更容易，也更易于维护)这样的东西时，您仍然有一个稍微大一点的学习曲线——尽管如果要保持所有东西都是最新的，那么学习曲线很可能是值得的。
也许有一天，整个Linux世界将走到一起，在所有发行版中统一使用单一的包格式。在那决定性的一天，我们都将维护一个单一的存储库结构和系统，使每台计算机，无论其分布如何，都能轻松地跟上时代并保持同步。
在那辉煌的一天到来之前，我们有AppImage、FlatPak和Open Build Service来让我们的生活变得简单一点。