Re: [PATCH] doc: ensure sphinx output is reproducible

[Luca Boccassi <bluca@debian.org>]

On Sun, 19 May 2024 at 15:01, Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 17/05/2024 13:29, Luca Boccassi:
> > On Mon, 27 Nov 2023 at 17:04, Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > On Mon, Nov 27, 2023 at 05:45:52PM +0100, Thomas Monjalon wrote:
> > > > 06/07/2023 14:49, Christian Ehrhardt:
> > > > > On Mon, Jul 3, 2023 at 5:29 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > >
> > > > > > 29/06/2023 14:58, christian.ehrhardt@canonical.com:
> > > > > > > From: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> > > > > > >
> > > > > > > By adding -j we build in parallel, to make building on multiprocessor
> > > > > > > machines more effective. While that works it does also break
> > > > > > > reproducible builds as the order of the sphinx generated searchindex.js
> > > > > > > is depending on execution speed of the individual processes.
> > > > > > [...]
> > > > > > > -if Version(ver) >= Version('1.7'):
> > > > > > > -    sphinx_cmd += ['-j', 'auto']
> > > > > >
> > > > > > What is the impact on build speed on an average machine?
> > > > >
> > > > > Hi,
> > > > > I haven't tested this in isolation as it was just a mandatory change
> > > > > on the Debian/Ubuntu side.
> > > > > And the time for exactly and only the doc build is hidden inside the
> > > > > concurrency of meson.
> > > > > But I can compare a full build [1] and a full build with the change [2].
> > > > >
> > > > > That is an average build machine and it is 35 seconds slower with the
> > > > > change to no more do doc builds in parallel.
> > > >
> > > > I would prefer adding an option for reproducible build
> > > > (which is not a common requirement).
> > > >
> > > Taking a slightly different tack, is it possible to sort the searchindex.js
> > > file post-build, so that even reproducible builds get the benefits of
> > > parallelism?
> >
> > Given the recent attacks with malicious sources being injected in open
> > source projects, reproducible builds are more important than ever and
> > should just be the default.
>
> Yes it should be the default when packaging.
> Why should it be the default for normal builds?

Build reproducibility is everyone's responsibility, not just Linux
distributions. There should be no difference between a "normal build"
and a "packaging build". As far as I know, it is still fully supported
for DPDK consumers to take the git repository, build it and ship it
themselves - those cases also need their builds to be reproducible.
Nowadays reproducibility is no longer a "nice-to-have", it's table
stakes, as especially after the cybersecurity executive order of the
US govt from some time ago, procurement rules are getting stricter.
See the "Reproducible Builds" paragraph under the "2.4 Harden the
Build Environment" section in this CISA document on supply chain
security recommendations:

https://www.cisa.gov/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF