Ubuntu是否构建了确定性的？ 为什么不？
Ubuntu是否构建了确定性的？ 我假设它们是，也就是说，如果我重新构建构建Ubuntu安装媒体的过程 ，我将获得与Ubuntu镜像上相同的图像（逐位，具有相同的校验和）。
Joanna Rutkowska（ Qubes OS发行版的首席开发人员）最近的post表明事实并非如此：
目前，大多数项目（包括所有Linux发行版）都没有确定性地构建
为什么不？
对于初学者来说，我不认为Rutkowska正在谈论确定性地构建安装媒体，而是关于包（deb，rpm）。
Debian正在重复构建软件包（ https://wiki.debian.org/ReproducibleBuilds ），但仍然有很多软件包不能以这种方式构建……
确定性地建立整个分销肯定更具挑战性。
不，他们不是。 让我们澄清一下这里的区别，
-
系统是否支持 “可重现的构建”？
是的，所有系统都支持确定性的包。
-
系统是否强制执行 “可重现的构建”？
不，虽然它确实有助于诊断问题，但正在努力使包装重现 – 无论如何都要报告和处理错误。
-
一切都毫无例外地可以重现吗？
差远了。
现在让我们定义“可重现的构建”
如果给定相同的源代码，构建环境和构建指令，则构建是可重现的，任何一方都可以重新创建所有指定工件的逐位相同副本。
构建环境的相关属性，构建指令和源代码以及预期的可再现工件由作者或分发者定义。 构建的工件是构建结果的一部分，它们是所需的主要输出。
现在让我们谈谈需要什么
查看此页面下的“如何” ，其中列出了三个标准
-
构建系统需要完全确定：转换给定的源必须始终创建相同的结果。 通常，不得记录当前日期和时间，并且始终必须以相同顺序写入输出。
-
用于执行构建的工具集以及更一般地构建环境应该被记录或预定义。
-
应该为用户提供一种方法来重新创建足够接近的构建3.，执行构建过程，并validation输出是否与原始构建匹配。
您可以在此处找到有关所有这些内容的更多文档 。
至于为什么Ubuntu目前不可重现，像Perl这样的东西目前都失败了，因为为了方便起见， -V存储编译器args – 他们正在等待GCC修补这个上游。 很多这样的function都可以简单地解决。 一些其他问题：一些手册页和程序具有编译的构建日期，其他人在可变路径中编译到共享库等。
不可重现不是问题或漏洞。 它只是使得更难以validation您没有被篡改，并且目前该function被视为更有价值。
您可以在此处关注Debian在确定性方面取得的进展