☰

Debian APT 软件包是否未得到应用程序开发人员的正式支持或认可？

tag-icon • tag-icon debian apt package-management repository opensource-projects
Debian APT 软件包是否未得到应用程序开发人员的正式支持或认可？

我想了解 APT 包的一般管理方式，考虑到我今天遇到的以下情况：

我试图将 MongoDB 添加到我的 Debian 机器上。apt search mongodb显示出不错的结果，在尝试安装之前我阅读了MondoDB 文档其中指出：

请按照以下步骤在您的系统上运行 MongoDB Community Edition。这些说明假设您使用的是官方 mongodb-org 软件包——而不是 Debian 提供的非官方 mongodb 软件包——并且使用默认设置。

由此，我明白并惊讶于我从 Debian 中得到的东西apt install是非官方由应用程序的开发人员。这听起来比“不推荐”更糟糕。

我确实了解 Debian APT 软件包存储库倾向于显示旧版本，并且永远不会赶上最新的前沿更新。有很多方法可以解决这个问题，但现在我对这些词感到担心非官方。这是否意味着 APT 存储库中与 MongoDB（或任何其他应用程序）相关的软件包未得到应用程序开发人员的正式批准？或者它是由开发人员正式发布但“避免因为它不是最新版本”？或者有人（某个实体？）从官方安装包中复制并粘贴到APT？

我并不是想理解 MongoDB 的这个具体案例。相反，我想了解应用程序和 APT 的整体“政治”。它是如何工作的，它应该如何工作？

如果这是一个菜鸟问题，那么我很抱歉，但我在网上找不到很好的解释。任何链接或参考将不胜感激。

答案1

所有发行版（不仅是 Debian）中的软件包通常不是由应用程序的开发人员打包的，而是由发行版社区的成员打包的，通常称为打包者或包维护者。有时应用程序开发人员也可以是某些发行版中的打包者，但这不是规则，开发人员绝对不能在所有发行版中维护他们的应用程序（例如我在 Fedora 中维护我的软件，但在 Debian 中它是由其他人打包的）。

当谈到“批准”和“官方”或“非官方”时。我们在这里讨论的是自由软件，许可证允许分发软件，因此您不需要任何人的批准即可打包软件进行分发。开发人员可能不同意他们的软件打包和交付的方式，但这就是他们所能做的。

我不确定是什么让这个包成为（非）官方的。我想所有的软件包理论上都是非官方的，因为它们是由第三方制作的。这可能取决于您对（非）官方的定义。

可能导致打包者和开发者之间关系紧张的一件事是发布周期。发行版（尤其是“稳定”发行版，如 Debian Stable 或 RHEL/CentOS）有自己的发布周期以及对软件和 API 的承诺稳定这通常不同于上游发布周期。这就是您在发行版中看到旧版本的原因，通常带有一些错误修复向后移植。有时上游开发人员不喜欢这样，因为他们会收到已修复但未向后移植等内容的错误报告。有时打包者会自己决定编译时选项和其他更改软件（默认）功能的内容，这也很烦人。因此，开发人员会告诉您“使用我们的‘官方’软件包而不是您的发行版软件包”之类的内容，然后由用户决定什么最适合他们。

答案2

主要问题是：“官方”根据谁？某件事是否是“官方”很大程度上取决于您所问的是哪个“办公室”！

根据 MongoDB 开发人员的说法，MongoDB 开发人员分发的软件包是“官方”软件包。根据 Debian 开发人员的说法，Debian 开发人员分发的软件包是“官方”软件包。

在某些方面，两者都不比对方更“官方”全球的感觉。

分发包与供应商包不同的可能原因有很多：

  • 供应商软件包不支持该发行版支持的所有体系结构。例如，MongoDB 仅提供适用于 AMD64 上的 Debian 的软件包。但Debian不仅支持AMD64，还支持armel、armhf、arm64、x86、mipsel、mips64el、ppc64el和s390x。因此，这意味着如果您在 RaspberryPi (ARM64) 上使用 Debian，则不会有来自 MongoDB 的软件包。
  • 供应商软件包不支持最新的发行版。 Debian 的最新版本是 Debian 11，但 MongoDB 仅提供 Debian 9 和 10 的软件包。
  • 支持分发的同时不支持供应商软件包。例如，Debian 版本通常会在下一个版本发布后由 Debian 安全团队支持一年（通常大约为 3 年）。此后，Debian 社区内有一个名为“Debian LTS”的志愿者团队，在最初发布后的长达 5 年内接管维护工作。后那，有一个名为“Debian ELTS”的第三方商业项目，它在原始版本发布后提供长达 7 年的支持。之后那，只要您愿意，您可以聘请 Debian 顾问来获得额外支持。
    例如，这意味着 Debian 8 仍然具有 ELTS 支持，但 MongoDB 没有提供相应的软件包。
  • 发行版开发人员保证他们发布的每个软件包在整个发行版生命周期内与他们发布的每个其他软件包一起工作，他们保证他们发布的每个错误修复都将向后兼容，等等。通常，供应商不会对以下内容做出相同的保证：他们自己的包裹。例如，如果您使用 MongoDB 软件包，并且更新破坏了一些随机的其他软件包，那么您将无法获得 Debian 的支持（因为您没有使用他们的软件包），并且 MongoDB 开发人员可能根本不关心该随机的其他软件包包足以提供错误修复。 （我并不是说 MongoDB 开发人员专门不关心，我说的是可能的的开发商一些小贩可能不关心。）
  • 有时，供应商软件包只是违反了有关如何为特定发行版打包软件的一些准则，因此发行版需要提供自己的软件包。例如，某些发行版对于哪些类型的文件应存储在哪些目录中、哪些目录需要只读等有严格的规则。

现在，事实证明，在这个特别的案件，Debian 实际上已经停止提供自己的软件包因为MongoDB 更改为不同的许可证。该软件包的最新版本mongodb是在 Debian 9 中。Debian 本身不再为 Debian 10、Debian 11 或正在开发的 Debian 12 中的 MongoDB 提供软件包。但是，Debian 9 中的软件包可用于 AMD64、ARM64、 x86 和 PowerPC 64 位小端，而 MongoDB 开发人员提供的软件包可用于 Debian 9 和 10，但仅适用于 AMD64。

一般来说，分销商提供自己的软件包的主要原因是因为分销商与软件供应商有不同的关注点和约束，因此软件供应商提供的软件包通常不能满足这些关注点和约束。

请记住，大多数分发包都是由无偿志愿者创建的，并且大多数分发包都会喜欢提供更多包裹，但缺乏人力。如果有一种方法可以让他们可以只需从软件供应商处获取未经修改的软件包并将其放入发行版中，他们通常会这样做，而不是将精力集中在其他地方。

答案3

发行版维护者可能会应用他们自己的一组补丁，而上游可能不会认可这些补丁。这可能会导致这样的情况。

发行版还可能对其提供的软件版本有某些政策，这些政策可能与原始创建者的想法不一致。

Debian 发生过很多相关事件：

一旦你更好地了解了开源，它就不再那么美好了。

Debian APT 软件包是否未得到应用程序开发人员的正式支持或认可？

根据经验法则，这个问题的答案是“不”，而且不仅适用于 Debian，也适用于其他发行版。

例如，检查https://bugzilla.kernel.org

请使用您的发行版的错误跟踪工具 此 bugzilla 用于报告针对上游 Linux 内核的错误。

答案4

这是否意味着 APT 存储库中与 MongoDB（或任何其他应用程序）相关的软件包未得到应用程序开发人员的正式批准？

的确。 “自由软件”（GPL 意义上的）意味着任何人都可以获取您的源代码，对其进行修改，然后在未经您批准甚至根本不通知您的情况下重新分发它。

几乎所有开源项目的开发人员都会要求用户在报告错误之前尝试最新的可用版本。从这个意义上说，任何第三方软件包都是非官方的：如果它们有效，对您有好处，如果它们不起作用，您应该将此报告给软件包维护者，而不是开发人员。

相关内容