图片来源：来自Unsplash的KelliMcClintock我遇到过很多次用户抱怨LTS和稳定应用程序包的问题，??但随后声称开发版本从未发生过这种情况。然而，以我在封装技术方面的经验和知识，我怎么强调都不为过。分发模型不是问题的根源，根本问题是传统的包格式不适合现代图形应用程序，无论是什么分发。那么像Nix和Flatpak这样的格式是如何解决这些根本问题的呢？有趣的是，大多数服务器确实利用容器化（即Docker），因为它提高了可重复性和增强了可维护性。我们可以从中得到启发，为Linux桌面采用类似的标准。免责声明“传统包”是指使用包管理器而非容器发布的图形应用程序，例如apt、dnf、pacman等。“发布模式”是指发布过程，例如长期支持(LTS)、稳定版，开发等。“相似的应用程序”是指两个在技术上非常相似的应用程序，例如VisualStudioCode和Code-OSS。在这些示例中，我将使用ArchLinux作为参考。但是，这些行为与大量采用传统包格式的发行版一致。Nix不使用容器，也不是容器格式。但为了简单起见，我暂且将其称为容器格式。基本问题图片来源：Unsplash的JacksonSimmer大多数（可能不是全部）大量采用传统包格式的发行版都有这个问题：它们都没有使用容器或其他方便的方法来分离依赖项。通俗地说，容器就是一个盒子，我们可以在里面放东西，独立使用，不影响主系统（主机）。容器通常不会影响“盒子”之外的任何东西。它们是可移植的，因为它们可以安装在其他发行版上，同时提供一致的体验。使用容器的包管理器会将每个包安装在单独的容器中，这提供了额外的安全层。这让开发人员在决定将什么捆绑在包中时有更多的控制权和灵活性。传统的包格式会产生依赖和包冲突等问题，这些问题通常需要解决，不同的发行版有不同的解决方案。依赖项和包的冲突如果我们尝试安装VisualStudioCode(visual-studio-code-bin)，并且Code-OSS(code)已经安装在ArchLinux上，我们会遇到这个问题：$paru-Svisual-studio-code-bin[...]::发现冲突：visual-studio-code-bin:code::必须手动确认冲突包Aur(1)旧版本新版本仅制作aur/visual-studio-code-bin1.70.1-1否这就是所谓的包冲突，即两个或多个包不能共存。在这种情况下，我们不能同时安装VisualStudioCode和Code-OSS。当两个应用程序或软件包提供相同的文件、具有相同的名称并且放在同一目录中时，它们实际上不能共存，因为文件会发生冲突。本例中VisualStudioCode和Code-OSS都提供了一个名为code的文件，放在/usr/bin下。VisualStudioCode提供的代码文件用于启动VisualStudioCode，Code-OSS的代码文件用于启动Code-OSS。虽然此示例仅显示VisualStudioCode和Code-OSS，但这经常发生在不同的应用程序、库和其他软件中。无法选择依赖项图片来源：来自Unsplash的PriscillaDuPreez传统包格式的最大问题之一是打包者无法选择依赖项。例如，如果一个应用程序最近更新为依赖程序A的版本1，但发行版仅提供程序A的0.9版本，则升级该应用程序并不理想，因为发行版无法满足要求。这意味着打包者将不得不推迟打包，直到为该发行版发布新的依赖项或解决它。同样，如果应用程序依赖于程序A的0.8.1版，但分发版仅提供程序A的0.9版，则该应用程序将无法正常运行或根本无法运行。修补库和构建配置为了扩展，一些应用程序需要修补库或额外的构建配置才能正常运行。例如，OBSStudio需要打补丁的FFmpeg才能更好地与OBSStudio集成。在传统的包格式中，一次只能安装一个依赖项的一个变体。如果发行版提供未打补丁的FFmpeg，则无法安装已打补丁的FFmpeg，除非打包程序可以修复此问题。如果你安装了打过补丁的FFmpeg，但另一个程序高度依赖未打补丁的FFmpeg、打了其他补丁的FFmpeg，或者打了其他内置或删除功能的FFmpeg，那么其他程序就会有bug。现代应用程序本质上是脆弱的。依赖树中的一个小错误或不一致都会导致应用程序出现错误，恶化用户体验，甚至让人觉得问题出在应用程序而不是包本身，从而阻碍应用程序的开发。名声。变通办法让我们看看开发人员目前用来打包他们的应用程序的变通办法：第一个变通办法是将依赖库安装在不同的目录中。例如，Electron是一个巨大的框架，开发人员可以使用它来构建应用程序，然后将它们捆绑在一起。然而，基于Electron的应用程序是不同的，因为它们构建在不同版本的Electron之上。Discord捆绑了Electron13，Element捆绑了Electron19。对于ArchLinux上的Electron打包，某些目录需要安装在/opt/APPLICATION_NAME中，这样这些Electron版本就不会相互冲突。第二种解决方法是篡改应用程序。例如，将应用程序打补丁使其在没有某些依赖库或功能的情况下进行编译可能会使应用程序成功编译，但不能保证应用程序将按预期启动或工作。第三种解决方法是在编译应用程序时禁用许多编译选项，这也可能会禁用某些功能。例如，在ArchLinux上，OBSStudio在编译时禁用了许多基本功能，这导致了不合标准的体验。这些变通办法因人而异，有些会限制应用程序的功能，有些会引入稳定性问题，等等。不一致的体验图片来源：来自Unsplash的alevision.co虽然这些技术限制在传统的包格式中是一致的，但用户体验往往并非如此。由于包的分发方式，与传统包格式相结合的分发模型会影响用户体验。一些发行版，例如ArchLinux，接近开发版本，因此拥有最新版本的软件包。但是，Debian和UbuntuLTS是LTS长期支持版本，所以他们的很多包都落后了好几个版本。同时，FedoraLinux和UbuntuStable介于Debian/UbuntuLTS和ArchLinux之间。一些包格式喜欢尽可能少地修补包，以使其尽可能接近原始包；而其他人则通过补丁来添加更多功能、使用旧库或进行其他类型的更改以改善用户体验。有些格式喜欢保持软件的轻量级；其他人则喜欢添加尽可能多的内置功能。包裹有各种各样的习惯和喜好。正如我们所见，应用程序在不同的发行版中构建起来非常不同。此外，不同的发行版具有不同的依赖性。传统包格式的许多技术限制需要不同的方法，具体取决于分发模型和打包策略。这些微小的变化往往会给用户带来不完整、不合标准的体验和错误的印象。某些应用程序可能在某些发行版上运行得更好，但在其他发行版上可能运行不佳，而其他应用程序运行得更好。尽管应用程序在每个发行版上的构建方式不同，但其名称和品牌保持不变，给用户留下了错误的印象。解决方案图片来源：Unsplash的RiccardoAnnandale如上所述，这些问题的解决方案是使用容器。容器旨在分离系统的多个方面。通过使用容器，打包者可以挑选和选择依赖项，而不受主机上的库的限制。因此，打包者可以发布最新的、功能完整的包，同时保持发布稳定性。这很重要，因为这些容器格式允许应用程序和发行版在不破坏系统的情况下充分利用它们。Nix和FlatpakNix是一个跨平台的包管理器，可以在类Unix操作系统（例如Linux发行版、BSD和macOS）上运行。Nix有多个渠道（分支）可供用户使用。另一方面，Flatpak是一种用于Linux桌面的通用包格式，它也使用容器，但另外还有一个沙箱来隔离它们。它旨在将来可供普通人使用，并旨在与GNOME“Software”和KDE“Discover”等软件商店集成。换句话说，Flatpak更像是一个发行版的扩展，而不是一种软件包格式的替代品，因为它并不是为了取代系统包管理器而设计的。如果使用NixOS等发行版，Nix也可以用作扩展或独立使用。类似的应用Nix和Flatpak解决了传统封装格式的许多基本问题。由于应用程序的分离，这些格式可以安装类似的应用程序，例如VisualStudioCode和Code-OSS，而不会发生冲突。多个版本Nix和Flatpak可以安装同一应用程序的多个版本。使用Nix，我可以从nixpkgs-stable(LTS)安装应用程序，同时从nixpkgs-unstable（开发版本）安装相同的应用程序。同样，使用Flatpak，我可以同时从稳定版和测试版分支安装应用程序。我可以继续从更多途径和分支安装相同的应用程序而不会遇到冲突。Pickydependencies图片来源：来自Unsplash的Ishdeloyola此外，打包器可以将应用程序与库的不同变体捆绑在一起，从而有机会启用更多构建选项并使用修补的或特定版本的库来为用户提供完整的体验。这意味着打包者可以将打过补丁的FFmpeg与OBSStudio捆绑在一起，仅供在OBSStudio中使用。如果我在主机上安装纯FFmpeg，那么OBSStudio的修补FFmpeg将不会干扰或冲突主机的FFmpeg。环境在各个发行版中是一致的。如上所述，每个发行版都使用不同的补丁、构建选项和环境来构建应用程序。这会导致应用程序碎片化，每个应用程序的构建和工作方式通常各不相同。由于Nix和Flatpak旨在跨发行版运行，因此它们为每个发行版中的应用程序提供了一致的环境，前提是该发行版提供了Nix或Flatpak的支持版本。缺点与所有事物一样，Nix和Flatpak也不完美。随着最近容器技术在Linux桌面上的兴起，它们可能会为许多应用程序提供一个不寻常的环境。Flatpak不仅包含应用程序，还将它们沙箱化。Flatpak的开发人员已经实施了一种短期解决方法来“在沙箱中打孔”，称为静态权限。他们正在研究一种称为XDG门户的适当的长期解决方案，以解决沙盒的许多问题，并使其类似于Android的安全模型。唯一的短期问题是工具包、框架和应用程序必须采用这些标准。GTK和Qt等工具包集成了其中一些门户，但它们也需要时间来集成其他门户。同时，许多其他工具包还没有真正集成任何门户。工具包、框架和应用程序采用这些新标准只是时间问题，因为在XDG门户之前还没有任何标准。应用程序可以直接访问文件系统和API，因此静态权限保持这个“标准”。结论传统包格式的根本问题在于它没有利用容器。许多图形应用程序本质上都很复杂，需要非常特定的依赖关系才能按预期运行。许多发行版通过使用变通方法（例如修补应用程序或禁用某些构建选项）在不同环境中构建相同的应用程序。这导致了应用程序的不同变体、不一致的行为和不合标准的用户体验。当然，发行版的维护者不太可能在几天内真正重写他们的包管理器并使用容器。这些重写会破坏很多脚本、功能等，并且需要很长时间才能投入生产。我个人的建议是使用和推广Flatpak，因为它只是为了扩展现有的发行版，而不是取代它。打包者不必担心打包应用程序和求助于变通方法，因为Flatpak已经解决了这些问题。作者HariRana最初发表于此博客。Hari是FedoraMagazine的Fedora编辑委员会成员。他还是Fedoea质量保证(QA)的一员。Hari希望通过推广各种技术和帮助有需要的人来为Linux桌面的采用做出贡献。本文所表达的观点和意见是作者的观点，不代表我们的观点。
