为什么存储库中有预编译的包?

Ben*_*Ben 15 linux packaging source repository

我喜欢 Linux & Co. 如何让用户从不同的存储库安装许多软件包。AFAIK,它们还附带源码包,所以你可以自己编译它们。

但是,当您可以自己编译它们时,为什么还要费心“保留/提供”预编译的包呢?保留/提供它们的意图是什么?

是否可以配置Linux,只下载源包并让操作系统完成其余的工作?(就像预编译包安装一样?)

谢谢您的回答。

Ste*_*itt 57

它\xe2\x80\x99是一个权衡:提供预构建包的发行版花费时间构建它们一次(在它们支持的所有配置中),然后他们的用户可以安装它们而无需花费时间构建它们。用户按原样接受 distributions\xe2\x80\x99 二进制文件。如果考虑一些较大发行版的软件包安装数量,则不需要到处重新编译所节省的时间是相当可观的。

\n

有一些发行版提供源代码和构建它所需的基础设施,并依赖用户在本地构建所有内容;参见Gentoo 的例子。这允许用户准确控制他们的包的构建方式。

\n

如果您沿着这条路走下去,即使通过简化包构建可以节省时间,您也应该准备好花费大量时间来构建包。我不\xe2\x80\x99t 维护 Debian 中最复杂的软件包,但我的一个软件包需要两个多小时才能在 64 位 x86 构建器上构建,而在较慢的架构上则需要十二个小时以上

\n

  • 最严重的罪犯是 [Chromium](https://buildd.debian.org/status/fetch.php?pkg=chromium&arch=amd64&ver=103.0.5060.114-1&stamp=1657530943&raw=0)(在 x86 上超过十个小时)和 [LibreOffice ](https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=amd64&ver=1%3A7.3.5%7Erc1-1&stamp=1656768667&raw=0)(在 x86 上超过六个小时),远远领先于任何编译器(LLVM 13 大约需要三个小时,只比 GCC 12 多几分钟)。 (14认同)
  • @Oliphaunt 海湾合作委员会甚至不是特别恶劣的罪犯之一。根据我的经验,LLVM(在 Linux 上构建 GPU 加速图形环境基本上已成为强制性要求)需要大约 10-20% 的时间,而大多数 Web 浏览器至少需要 50-60% 的时间(有趣的事实,即使将所有内容都扔掉)在 Ryzen 9 3950X(32 个执行线程)和 64GB DDR4-2666 RAM 上,webkit-gtk 的构建时间仍然超过 45 分钟)。 (8认同)
  • @Voo 我仍然记得在 90 年代初从源代码构建 X11(或 gcc)。*如果*一切顺利,该过程将需要 1-2 天。这不是我想回去的做法。 (5认同)
  • 除了一个很好的答案之外,感谢您链接该构建日志。我刚刚浏览了所有内容。即使这也花了相当长的时间。这令人难以置信。 (3认同)
  • 除了花费的时间之外,我什至不想考虑尝试构建仅具有 4GB 内存的 Chromium(如果您只有一个小型 SSD,则所需的额外磁盘空间也可能是一个问题)。 (2认同)

Art*_*nov 26

  1. 你暗示所有人都有足够的 CPU/RAM/存储/时间/知识来编译包。不,事实并非如此,事实恰恰相反,大多数人绝对不想等待几个小时来编译某些东西。Raspberry Pi 上的 Firefox 编译可能需要几周时间。这个可以吗?没有。

  2. 第二个原因是 Linux 发行版在受控的无恶意软件的正常运行环境中构建软件包,但无法保证最终用户能够正常运行。

  3. 该发行版的所有用户最终都运行完全相同的代码,这有助于报告错误和调试,这对于决定自己编译软件的用户来说可能并不正确。

  4. 许多现代 Linux 发行版都支持安全启动,这需要使用无法在最终用户之间分发的密钥对软件包进行签名,因为这意味着您的信任链完全被破坏。

欢迎您在 Arch Linux 中使用 Gentoo、LFS 或 AUR 存储库构建一切。实际上,大多数发行版都可以编译软件包,但以上三个发行版是在创建时考虑到编译的。

  • 举一个极端的例子来说明你的第一点,我运行 Linux 的最旧的计算机是 Pentium MMX。编译GCC 6.4花了四个月;从 GCC 发布时间表和较新计算机上的编译速度推断,我预计 GCC 13(可能还有 GCC 14)将在完成 GCC 12 编译之前发布。 (6认同)
  • 与 Gentoo 和 LFS 不同,Arch 将软件包作为二进制文件分发。 (2认同)
  • 关于2,我通常信任我使用的发行版及其包维护者,但我认为用户编译的包更安全。如果用户被感染,那么他们就已经被感染了。然而,将编译留给发行版的维护人员可能会导致有人成为不良行为者并在编译的软件包中包含恶意软件。虽然我相信源包和预构建包通常都是安全的,但我不认为预构建包比源包更安全。选择源码包的理由主要是安全性。 (2认同)
  • @StephenKitt 从安全角度来看这并不重要。出于安全目的将源代码与二进制文件一起发布只是一个安全剧场。如果您不能信任源代码,那么它是否只是二进制文件、二进制文件+源文件或只是源文件都没有关系。它们都可以被操纵。为了验证此类操作,您在所有情况下都需要第二个值得信赖的来源,此时只需删除存储库并使用您信任的来源即可。 (2认同)

Jör*_*tag 20

\n

但是,当您可以自己编译它们时,为什么还要费心“保留/提供”预编译的包呢?保留/提供它们的意图是什么?

\n
\n

简单的经济学。即使在大型集群上,编译整个发行版的软件包也需要数周时间,会消耗大量能源并产生大量热量。

\n

仅执行一次此操作比为每个用户一遍又一遍地执行此操作更有意义。

\n

它还极大地增加了基本安装的大小和复杂性(从而增加了攻击面!!!),因为您必须包含每个软件包作为基本安装的一部分使用的每种编程语言的每个编译器。

\n

很多很多年前,我非常喜欢Linux From Scratch,并且编写了一个脚本来自动执行基本 LFS 系统的整个安装过程。它运行了大约两天,只要记住基本的 LFS 系统是一个非常基本的系统系统。它包括内核、libc、shell、引导加载程序和一些基本工具 \xe2\x80\xa6 ,仅此而已。没有图形环境,没有网络浏览器,没有电子邮件程序,没有办公套件,没有多媒体播放器,没有Java环境,没有Python / Ruby / PHP / Node.js /无论您喜欢的编程语言是什么,没有游戏,没有照片编辑器,没有科学工具,而不是真正使计算机“有用”的所有东西。

\n

其中一些非常大,需要很长时间才能编译。编译一个包可能很容易需要几周的时间,具体取决于您运行的计算机。(想象一下您的路由器或智能手表。)

\n

  • +1 提及环境影响。 (7认同)
  • @Voo类似的东西,是的;我手头没有当前的数据,128GiB 可能还不够,但 256GiB 应该可以轻松完成(40-60 个核心)。 (2认同)

MC6*_*020 11

自从我从 FreeBSD 迁移到 gentoo 用户以来,Pfff!是在十年前,我非常同意斯蒂芬和阿尔乔姆的答案,我确实投了赞成票。

\n

我从来都不是那些相信为 gcc 设置迷人的个人选项(例如考虑 -funroll-loops -fomg-optimize)会带来显着性能提升的人,尽管这是绝大多数人声称的主要原因之一编译瘾君子。

\n

在我的 core II duo 系统上\xe2\x80\xa6 当然\xe2\x80\xa6 编译 chromium 将需要超过一整天的时间\xe2\x80\xa6 :简直\xe2\x80\xa6 荒谬!如果你想跟上上游的更新步伐,那就更愚蠢了!

\n

荒谬的 ?好吧,归根结底,\xe2\x80\xa6 不一定是 \xe2\x80\xa6,这取决于你真正关心的是什么,因为有些事情你不能只用预构建的包来实现

\n
    \n
  • 例如,避免使用 firefox 进行脉冲音频。
  • \n
  • 更喜欢依赖系统共享库而不是本地实现(harfbuzz、icu、apng、libevent,更不用说编解码器(av1、vpx、webp\xe2\x80\xa6)(更不用说专有编解码器\xe2\x80 \xa6)))
  • \n
  • 最终\xe2\x80\xa6 只要你有足够充分的理由偏离上游选择。(你的硬件过时只是一个例子)
  • \n
\n

如果你没有得到任何这些遗嘱,那么\xe2\x80\xa6 那么\xe2\x80\xa6 只是认为这显然不是一个环保的方式来维护你的系统\xe2\x80\xa6 几个gentoo首席开发人员因此退出。

\n

  • 已经有一段时间了,但我运行了一个基于 Gentoo 的生产 HPC 集群。主要用例是分子建模和序列分析。在构建包括内核在内的所有内容并针对所使用的特定芯片组进行优化后,我发现运行时间减少了约 4%。当作业运行 4 周时可能很重要,但在其他情况下不值得付出努力。 (5认同)
  • USE 标志——调整包的编译设置(而不是编译器)的能力——确实是 Gentoo 中的一个非常巧妙的功能。 (2认同)